I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice. For academic languages this may not matter, but if you actually want your language to be used, you need to pay attention. A recent study[1] has shown that "extrinsic" factors (performance, tooling, familiarity, libraries) matter a lot more than intrinsic factors (syntax, abstractions) when it comes to adopting programming languages. A language that understood this beautifully was Java[2] (and, I believe, Go, which is very much in the spirit of the Java philosophy), that analyzed existing "advanced" languages like Scheme, Self and Modula (and indeed some of the people involved with those languages were among Java's early designers) and realized that the features that give those languages most bang-for-the-buck weren't clever abstractions but extra-linguistic features such as GC, dynamic linking and JITs[3], that can be packaged in a crude, "blue-collar" language that's familiar (and familiarity is indeed among the top factors in choosing a language, while "correctness" -- as in more powerful type system -- and particular language features are among the last). James Gosling called it a wolf in sheep's clothing. A wolf in wolf's clothing may look more fierce, and the sheep's clothing may indeed limit its maneuverability a bit, but it can still be almost as wolfish, yet much more palatable.
OTOH, Kotlin took whatever it could from Ceylon (the nullability types, flow-sensitive typing) while keeping 100% seamless interoperability with Java as the top priority, so it may not be a revolution, but its adoption costs are virtually zero. It doesn't even have much of a runtime library; it was designed in such a way that all cool features could be applied to Java's standard library. The idea was that abstractions are great as long as they don't come at the expense of more important features, such as availability of libraries, tools etc (Kotlin even supports Java's annotation processors, so popular libraries that rely on compile-time verification/code-generation such as Dagger can work on Kotlin code).
Of course, I take this much further than you and believe, unlike you, that the contribution of advanced language-level abstractions is not so pronounced at all (or, at least, it hasn't been shown to be significant), and obviously I have a very different perspective on Scala than you, but at least we can agree on something :)
[3]: Sun had experimented with a JIT for Self long before it was introduced to Java, and the plan was to make Java exploit JITs almost from the get-go.
OTOH, Kotlin took whatever it could from Ceylon (the nullability types, flow-sensitive typing) while keeping 100% seamless interoperability with Java as the top priority, so it may not be a revolution, but its adoption costs are virtually zero. It doesn't even have much of a runtime library; it was designed in such a way that all cool features could be applied to Java's standard library. The idea was that abstractions are great as long as they don't come at the expense of more important features, such as availability of libraries, tools etc (Kotlin even supports Java's annotation processors, so popular libraries that rely on compile-time verification/code-generation such as Dagger can work on Kotlin code).
Of course, I take this much further than you and believe, unlike you, that the contribution of advanced language-level abstractions is not so pronounced at all (or, at least, it hasn't been shown to be significant), and obviously I have a very different perspective on Scala than you, but at least we can agree on something :)
[1]: Paper: http://lmeyerov.github.io/projects/socioplt/papers/oopsla201... Accompanying talk: https://www.youtube.com/watch?v=v2ITaI4y7_0
[2]: https://youtu.be/Dq2WQuWVrgQ?t=14m12s about why Java was designed the way it was
[3]: Sun had experimented with a JIT for Self long before it was introduced to Java, and the plan was to make Java exploit JITs almost from the get-go.