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.
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.
Which is pure opinion/speculation.
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.
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.