Even writing you frontend in Java first would (most likely) not have helped you coping with the new-found challenges in that heights.
And not every low-traffic site is simple CRUD. If you do image processing, applying machine learning, natural language processing (or a thousand other things that are CPU intensive), it's nice that you can directly use one of the many high-performance libraries available in the Central Repository in your webservice.
Also, the example was the Twitter frontend. So I respond to Twitter frontend. Don't derail.
I'm sure they could get a speedup by rewriting the front-end, but the fact that they kept trying and fail to scale stuff that with anything remotely like a sensible architecture is network IO bound rather than CPU bound even with MRI on the hardware available when they launched was a good sign that their main problem had nothing to do with language.
Their "simple" case of updating n followers for every status update when n is small is trivially distributable with a relatively simple message bus routing fabric; their "hard" case of updating when n is excessively large is simple-ish by simply structuring the follower lists as a tree of "virtual" follower lists that acts as forwarders; you can do that with off the shelf components.
To illustrate just how basic this problem is: I've built message buses for scenarios like that using mail servers even - though if you do that, at least with a standard mail server, you will be limited by disk IO on forwarding nodes unless you spend too much money (you don't need message updates to be durable "in transit", as if the system is suitably.
Another simple approach to the large follower problem is to pull from "expensive" publishers and push from cheap ones. You can do that too with 25-30 year old software and some scripts to maintain the lists: Push via SMTP, pull via NNTP and make the "mailbox" you post status updates to for people with large follower lists a SMTP->NNTP gateway.
No, I'm not suggesting they should actually do that, just pointing out that it is viable, and it was viable with the kind of data volumes they are dealing with well over a decade ago. Yet they had problems handling it years later with a much smaller data volume than they have now.
When you get to the size Twitter is now, it makes sense to sacrifice developer effort for saving some percents here and there on servers, but their complaints about language when they started their rewrites was distractions from the real issues, whether they realised it themselves or not - it's not like they were handling data volumes at the time that lots of people haven't managed to handle with much more modest resources.
Also, this is a question of resources. Once your first version succeeds, you suddenly have the funds to build a complex version where you care about all the small details.
Ruby is a _very good_ language as long as you are in the "I don't need to tune all the details phase".