Well you misunderstand scalability. Scalable DOES mean you can just throw more hardware at something, as you said. But you omit the part the scalability has limits. There's always a bottleneck, so no app is infinitely scalable. You take your best guess at what its intended audience will be and you proceed form there.
You can say my app's been designed so that it will scale when n is between 1 and 100,000 for instance. Or that it'll scale between 1 and 100,000,000,000,000. But the app you design for the later will be very different internally and take a lot more time to design. Most apps start out working only for small n because most apps will never get to big n or if they do, they do so gradually and give developers time to deal with it. Twitter was cursed by its own success, they didn't know it'd be as popular as it turned out.
Let's look at some specific technical details.
For most sites a single master DB server with slaves for reads is fine. Most apps out there don't need multi-master capabilities and thus implementing that would be a waste of time. In fact, most web apps you see out there are designed to run on a single DB server for reads and writes.
When Twitter started that's what they had and it worked. Then twitter got unexpectedly popular, and at that point in time Rails did not support multiple DB connections per instance, so sharding wasn't really possible. Days after they announced this problem it was fixed so it's no longer an issue.
We could speculate on problems they've had since then, but that would just be speculation. They've said repeatedly however that their stack's scalability issues have been in the non-rails parts (like the DB). Since they're the only ones who actually know what's going on, I'm inclined to believe them.
Let's look at some other social app failures,
An example would be myspace, which had horrible problems scaling, even though that was written in PHP which you consider to be super scalable. Or we could look at friendster, which was written in enterprisey java, which also had huge scaling problems. It's not the tool, it's how you use it.
Additionally, when you scale real world systems you just may find out the bottlenecks aren't where you thought they'd be during the design and testing. Runaway successes like twitter are vulnerable to this fact.
If you want to fault the Twitter engineers you really can only fault them for bad judgement in estimating the size of their user base. I don't think you know what Rails actually is. It's just helpers for YOUR code. Ultimately, a rails site is mostly your code, and your architecture.