Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.
Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.
If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.
So the important questions are:
1. Does Rails performance degrade gracefully under load?
2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?
In my experience, the answer to both of these is 'no'.
(But these challenges are hardly unique to Rails.)
About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.
Implying that Twitter reached success under Rails, even if it was _not_ the best fit for the problem set.
Dumping Rails when you have won the market is a nice luxury to have, one that most people on HN do not have.