Hardware is generally cheaper than developers -- especially the really rare MySQL wizard that groks the SELECT procedure deeply enough to be able to rewrite them to use fewer disk seeks.
The thing is, the stuff they missed in their SQL queries doesn't even need a MySQL wizard in blue cape to grok. There were no JOINs, no subselects, nothing high SQL magic at all - an average self-taught DBA would spot the suboptimal index usage. They should have totally solved it themselves.
I was just casually browsing this article because I don't know much about DBs, but if you tell me that there's a problem that can be solved by throwing more hardware at the problem or hiring a very skilled optimizing DBA, I would take hardware 19 times out of 20. I'm not disputing the software solution is technically feasible, just that it seems like a risky bet.
The funny thing is that they still can't skip "a very skilled optimizing DBA" step even with the NoSQL solution. They still need a database architect, and they still need to optimize their queries. But this time, finding a good DBA would be much harder since I imagine the number of NoSQL specialists (and in them the number of experts specializing in Cassandra) must be much lower than the number of good MySQL DBAs.
Of course, now that they have a system that supposedly scales with a simple addition of new hardware to the farm, they may get away from optimization for some time - if their DB architecture is good.