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.
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.
The distinction I want to draw is between types of teams. Some teams are very very organic, they let most of their developers do their own thing and they come together relatively independently. In these teams, having the language dictate approach isn't just handy, it's critical to keep the system coherent. You can instantly say during code review “yeah, that's not how it's done in Clojure”. Scala doesn't have the same level of guidance. Style is dictated by the frameworks you choose, and even then there's room for error. I use style, by the way, not as meaning “please use two spaces instead of tabs”, but rather as “parameter order in these cases should be this, method names should be structured like this, our class names usually look like this”, etc.
The other team is the team that has a clear single or group of guiding individuals who have a vision of how they want the system to work on a stylistic level, and who can explain that vision to the rest of the team. For these types of teams, where those individuals enjoy the process of coming up with the vision, Scala can be exactly what they're looking for, because they can develop the style that fits best with the system they're building. This shouldn't be confused with architecture. Architecture is important, but style is not a subset of architecture, it's an overlapping set.
A choose-a-phone is difficult for a single instrument player who is used to constraints, but for someone who likes to push the edges of constraints and come up with just the right combination of sounds for this particular piece, a choose-a-phone gives them the freedom to do that without having to pull in seven different instruments. Indeed, if we could make a choose-a-phone, I doubt every symphony composer would shirk it—I suspect some would embrace it. Not as something for research, but as something that lets you produce a different kind of musical piece. It wouldn't work for every composer or orchestra, but for those who could establish a coherent sound from the vast range of the choose-a-phone, it would be a fantastic opportunity to create something new and, from some perspectives, better.
The way I've successfully used Scala has always been about discipline. You choose the path you want to follow through the language, and you stick to it via code review. If you discover a new corner or feature of the language, you discuss its usefulness and choose to either incorporate it into your existing processes or not. Could you just say “let's use this other language for this”? Yes. But Scala lets you explore a large set of opportunities within a similar syntax, and use them where they are appropriate. If the syntax is what bothers you, or if the particular approach to a given piece of functionality is what bothers you (this has happened at times in my experience), then you can explore a different language; Scala certainly doesn't preclude you from doing that. But your first forays and prototypes can be within the context of a language everyone on your team already knows, making for a smaller incremental step. Smaller incremental steps mean faster iteration, and faster iteration means faster decisions on whether something is a good idea or not.
Scala more than many other languages doesn't dictate approach. But that doesn't mean approach doesn't matter. It means the approach ball is in your court. Pick the wrong one, and your experience will probably suck. Let that taint your view of the language if you wish, but keep in mind that there may be an approach that will be a lot nicer. For some people and some teams, that's not what they want out of a language, and that's fine. For some people and some teams, that's exactly the kind of empowerment they want, and that's fine too.
There is no difference in practicality, only in personality.
PS: I love Clojure and Erlang, too ;)