I am not sure if I buy the "it's nobody's fault" explanation. From what I gather, what they built simply did not work, even though it was clearly feasible. They had a failure of engineering and could not afford to rebuild the entire app. I know nothing about the specifics of the architecture, but I do know first-hand that if using Rails as the basis of an efficient and high-capacity SaaS backend, it is the wrong decision.
I think the problem here is that they choose a technology that is difficult - but not impossible - to scale, and they didn't have either the in-house know-how to solve their problems neither the money to hire someone with the knowledge to do it.
I think RoR could have been a good decision a few years ago, when the web framework landscape what atrocious, but nowadays there're a lot of good options based on other programming languages that have already proved could be scaled without finding untraceable bugs. Heck, just a few days ago an acquaintance showed me a webapp running over a perl - Amazon, IMDB, Slashdot... use perl heavily - async framework 20% faster than node.js.
I was going to write a sarcastic reply saying "Whoops! Better tell all [major companies using Rails] that they made the wrong decision" but honestly, is it worth my breath? Haha.
Funny, but I disagree. Rails scales, if you know how... We serve millions of customers each month and have implemented a reliable and stable architecture.
Great question. In my career so far I have deployed Web apps in ASP Classic, PHP, ASP.NET and Ruby on Rails. It appears that RoR can only handle a small fraction of activity compared to the other technologies before maxing out system resources. There are some lighter weight Ruby frameworks out there (Rack, Sinatra) that are probably more appropriate for large-scale back ends. Still, I have not worked with any Web technology that is performant enough to confidently endorse.