I recall several discussions of it at the time, and I don't think it's so much that they weren't able to, as that they'd made lots of disastrous architecture decisions (building it around a monolithic database etc.) that required a rewrite, and whomever doing it used it as an opportunity to blame it on Rails as an excuse to switch to their preferred stack.

After all, sharding message distribution via federation (even if you hide the federation behind a veneer of a global userid -> shard mapping) was a well understood long before Twitter even launched (e-mail... reflectors...), so it was a rather embarrassing architectural decision to not even try to account for it. Heck, I co-founded a webmail provider in '99, and one of the first things we did was implement ways to map user ids to a distributed set of backends and support for migrating accounts between backends, because we knew it'd be necessary to be able to shard smtp servers, frontends, and storage separately. That wasn't in Ruby, but the architectural pattern is so obvious.

The language change may or may not have made sense for them at the time (after all Ruby was much slower then, and they by then had the size where a rewrite of core parts to cut hosting costs might have been worth it), but that they blamed their architectural failures on Rails was a cheap shot.

Normally such decisions come from "Senior developers", which are experts in other domains than ruby on rails. How often you see them wanting to write raw sql in rails, "because its faster" and/or "much easier".. this summarizes a lot that problem https://daedtech.com/how-developers-stop-learning-rise-of-th...