This seems to be a typical instance of conflating coincidence and causality. Twitter changed their architecture, which solved their scalability problems. At the same time, they also happened to introduce a new programming language, but this doesn't mean that this was responsible for fixing their problems.
Twitter was originally envisioned as a CMS platform. So, it was architected as a CMS, with a database at the center. However, users didn't use it as a CMS, they used it as a messaging platform. A database is pretty much the worst case scenario for a messaging platform: a messaging platform needs a message queue at the center. So, Twitter wrote a message queue that complements their database, and that helped their scalability problems somewhat.
This message queue was actually written in Ruby. So, no Scala there. (BTW: the name of the language is Scala, not SCALA. It's not an acronym.)
This first message queue also had scalability problems. Not because it was written in Ruby, but because it was the first time that any of the developers had ever written a message queue. So, they wrote another message queue. This time, they had all the experience from the first message queue, so this one was better. And it happened to be written in Scala.
The reason why Twitter had scalability problems at the beginning was not because of Ruby, it was because there had never been a Twitter before, and nobody knew how to scale it.
The reason why it scales now, is because they learned how to scale it, not because of Scala. (In fact, large parts of Twitter are still implemented in Ruby. Others are in C++, and there's some Erlang, too, I believe.)
Architecture scales. Good languages can make it easier to find performance and scalability bottlenecks (by simply having less code to look through), and make it easier to do large scale architecture refactoring (again: less code), but ultimately, it's about the architecture.