I know, and we have constantly lived along the edge of the cliff because of that. From a perspective of security it was a very poor design decision. By making those decisions you create a big security burden, the attack surface is very large, the impact of bugs is very large. These are the types of security consideration that have to happen at design time. In this case I would like to know more about, maybe it's being considered but not being discussed.
MY first reaction was about security as well. This change of paradigm is a recipe for disaster if security is not considered from the beginning because most of the assumptions change. If it's not done carefully (things like segregation between apps, access control to privileged JavaScript, etc)... it is going to pretty painful.
It could be more haste than incompetence. Anyway, if you think about massive brute force attacks like this, they are 'silly' easy no-brain attacks more likely to come from script kiddies who downloaded a tool someone else wrote than real attackers.
I think that a more reasonable explanation could be that the attackers were careless about building the dictionary. If it's built by parsing files and you feed the wrong file or the parser does not work correctly you end up with a dictionary with lots of bogus entries. That seems a simpler explanation than:
"The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client."
or
"This might be due to the brute force tool not properly interpreting comments in the dictionary file, or the attacker not understanding the comment notation"
I really like "This American Life", it's not related to technology directly but it's sometimes very inspiring about how people do things. Also listen to "Planet Money".
I agree, is not consuming prevents creating, it's consuming too much takes time from creating. In that sense, developing a good filter for crap would allow you to consume faster leaving more time for creating.
A second issue is that it's assuming that if you develop an efficient filter for incoming crap, that filter will be applied to what you generate. And that if that filter threshold goes beyond the level of your own ability to create, all you do is crap and you stop creating. The input filter does not have to be the same as the output filter.
This comes from an attempt to write valid JavaScript without using any letters or numbers. It's partly for the sake of demonstrating it's possible and part for security testing reasons, to show that poorly written input validation filters can be bypassed.