I can count on one hand the number of times I've had to do casting in Scala over the course of writing four different web applications of various sizes in it. Fine-grained control over side effects is only a benefit if you consider it a benefit, and is IMO far from the greatest benefit you can get from a strong, flexible type system. Easy mutability has little to do with type safety—indeed, type safety makes mutability marginally safer by at least holding you to a basic promise when you make mutations. I can't deny Scala is heavier than JavaScript, I suppose, for some definition of heavier that I assume means “has more features”, or means something that ends up equating to same.
To argue that writing software in both Clojure and Java (or pick 2+ other languages that all run on the JVM, of course) will leave you with an objectively lower complexity:benefit ratio than using a single language is a dubious claim indeed. I don't guarantee that just using Scala will always result in a lower such ratio, but you'd have to make a much better quantitative argument to convince me that you can have a lower ratio consistently by using different languages instead.
To deal in increasingly-divergent analogies one more time: if your work is in Las Vegas, you may not care that there are cheap supersonic flights to other cities. They will never compare to being able to do all of your work in Las Vegas, even if it means switching hotels depending on your needs on a given day.
I've worked on projects that used C++, Ada and FORTRAN; on projects that used Java, C, and some homegrown DSL; on projects that used C++ and Scheme. In all circumstances, the integration of languages proved simpler than "disciplining" the C++ programmers, and on the JVM that integration is a lot simpler than what we had to put up with back then.
Also, bear in mind that team members change, as do team leaders. That proved to be a big problem for C++ projects as the discipline changed over the lifetime of the project.
If you look at Odersky's presentation "The Trouble with Types" [1] at Strage Loop 2013, he describes Scala as a "type it to the max language" like haskell, ocaml or F#. He seems to be aware of the complexity problem and proposes a few ways to reduce some of the type complexity.
BTW, to reiterate some of what's been said in other comments, I am certainly not opposed to using Scala in "Ruby style" projects (though Clojure would be a better option for those, too, IMO); I do, however, think that it's a very bad alternative for large Java projects.
It will be based on Scala, and similar enough that, if things work out, we could have Scala.next without a Python 2 to 3 glacial transition.
Of course, Scala 2.1.x branch is making great strides as is, and AFAIK, the DOT language is still a research project, so not likely that we'll be seeing Scala.next anytime soon.
How big is the team? How many years of maintenance have you had on those projects? I remember C++ looked pretty awesome for a while. It was certainly great for one-man projects or small team. Then the problems started piling up. Thing is, C++ didn't have any good alternatives (maybe now we'll have Rust); Scala does.
That was not the point. The comparison is that Scala is to Java what C++ is to C.
Powerful and flexible but with a lot of baggage that ends up making it impractical.
If making analogies, a much closer analogy would be to say Scala is to Java what D or Rust is to C++.
As of lots of baggage - can you elaborate? Only null comes to my mind and it is never an issue - it was left because Scala is practical. Sure, there are some limitations imposed by the target platform like lack of TCO, lack of efficient suport for tuples/value-types, or RTTI for generics being not powerful enough, but Java-the-language has nothing to do with it. The same limitations apply to Kotlin and Ceylon.
Which is pure opinion/speculation.
So you do get choice, but it's more of a choice between a Paris-style and a New York-style Las Vegas hotels rather than between Paris and New York. Scala is Las Vegas, only it runs on the JVM which offers cheap supersonic flights between Paris and New York.
Also, the kind of team you describe can't really be a big one. I might see it working for 15 people; maybe 20 if they're really good. But 50 and up? I don't think it's going to work.