It's not a mess. It's a language in which you can do what you did in Erlang, or what you did in Haskell, or what you did in Java, not because it's taken all their features but because the core language is expressive enough that you can write a library rather than making a separate language. You can shape the language to the problem, not because it's complex but because it's simple. It reminds me of go (the game, not the language) - yes, you can build up these very high level patterns, consisting of dozens of pieces, and sometimes you look at a master's beautiful play and wonder how he ever found it. But the underlying rules are very simple, and it's always possible to take a pattern apart and see why it works.

So you get the expressiveness of a language like perl, or yes, C++; you can write in a huge variety of styles. But you don't get the problem where no-one can read anyone else's code, because underneath it all those styles are using the same language primitives. So even if you haven't seen a typeclass before, you can understand scala code that uses them, because it's just passing an implicit parameter of a certain type. Even if you haven't seen an actor before, you can understand code that uses them, because it's just a library of funny-named methods with particular semantics, and using pattern-matching in a particular way.

Yes, you could write two actors that access mutable fields in another object. Yes, you could write a method in the I/O monad that also calls println. But you wouldn't do these things by accident. In 3+ years of professional scala development (with several quite inexperienced team members) I've never seen a bug caused by inappropriate mutability or inheritance. Yes, it would be nice if the compiler could draw a distinction between pure functions, those that performed I/O, those that modified state, and those that had other kind of effects. But it doesn't seem to be necessary in practice.

Being able to use a single language means being able to use one set of tools, one set of infrastructure (the maintaining of which is often one of the more tedious parts of the job). It means not having to context switch, and not making mistakes because a similar-looking operation means something different in another language. It makes code reuse much easier (yes, even on the JVM - while it's possible to call from one language to another, an API designed for a different language will be cumbersome because it uses different conventions). Ultimately it's just a lot less mental overhead.