I think that as a research language Scala is very important. It meshes features found in many different languages (OO types, algebraic types, duck-typing, macros) into one compiler, and so teaches us a lot about how these features can interoperate.
But Scala wishes to be a practical language as well. As such, I think it is an exceptionally badly-designed language (which does not, in itself, merits bashing) that masquerades, or claims to be, a well designed one, and herein lies the problem.
As Rich Hickey so eloquently puts it in one of his talks[1], a programming language is like a musical instrument. Every instrument has properties that introduce constraints. A trumpet can only play one note at a time, while a piano has very limited sustain. These constraints do not limit the artistic expression of the instrument – they assist it. An instrument with no constraints is a "choose-a-phone", and as Rich Hickey says, no one wants to play a choose-a-phone. That is not to say that a rich piece of music cannot be composed for a piano-and-trumpet ensemble. In fact, the JVM, which Scala targets, is the perfect language-ensemble tool, as it offers a harmonic interoperation of different languages of different kinds.
Scala is the ultimate choose-a-phone language, with little or no constraints. When it removed the constraints by mixing all these disparate features, it lost most of their underlying justifications. It adopted JavaScript's duck-types but lost the simplicity of the language; it adopted Haskell's algebraic types, but lost the control over side-effects; it adopted Java's OO types, but again, lost their static-type simplicity. But JavaScript uses duck typing because it can keep the language itself dead-simple and easy; Haskell uses those sometimes-hard-to-grasp algebraic types because they offer safety and carefully controlled side-effects; Java has a basic OO type system because it offers some safety while keeping the language relatively simple. Scala takes these features but drops their reasoning; in the process it lost its coherence. So the challenge of programming Scala turns from the challenge of simply expressing your artistic ideas with your chosen instrument into keeping yourself in line without those helpful constraints. It makes playing a harmonious melody difficult.
Scala masquerades as a well-designed language because it includes all of these modern, cool, features. Each of these features is well designed. But putting all of them together is the opposite of good design. The whole, in this case, is much less than the sum of its parts.
All this is not purely philosophical. Languages like Clojure and Erlang tell the programmer "this is how you should write software", and if you need to do something else, you should integrate Java or C code. Scala, on the other hand, offers little guidance. Immutable and mutable variables are just as easy to declare; the "expression problem" is sometimes solved using OO and sometimes FP. As a research language - that's great; as a practical language, it can be destructive.
It is also wasted effort. While it is certainly true that sometimes "named types" are better while other times duck-typing is more convenient, or that sometimes you want simple mutability and sometimes you don't, or that sometimes pattern matching is better than polymorphism and sometimes the other way around, in 99% of the cases, either of these approaches works well. Good, working, efficient, complex software has been written in Java, Haskell, JavaScript and Lisp. Combining all those features into one language creates big, largely unnecessary, overlaps in functionality that mostly cause confusion. This wasted effort is not just a waste; it is downright harmful, because Scala has become a very complex language. So complex, in fact, that no one but veteran Scala experts can understand how Scala's linked-list is implemented.
It is also unnecessary because, as I've said, the JVM is a multi-paradigm environment. If one paradigm is better than another for different parts of your software, you can write parts of it in Java, others in Clojure, others still in Erjang, and others in Frege. Even then you'll find that one, simple, language is perfect for 98% of your project, while another simple language is the best fit for the remaining 2%.
I think Scala's designers are stuck in their PL-research point of view. It is immediately apparent that Scala is not a language that grew from developers' needs and problems (like Clojure and Erlang), but from a PL experiment. Some years ago it might have been OK to overlook much of Scala's complexity and use it as "a better Java". Now, Scala has become ever more complex, and at the same time, better designed practical languages for the JVM have shown up. Given the wide choice, I think Scala is now a particularly bad option for a practical JVM language, especially if you're working in a large team, as every complicating language feature causes compounded damage as the number of developers on your team grows.
[1]: http://www.infoq.com/presentations/Design-Composition-Perfor...