A new programming language that hopes to achieve wide adoption is a big deal. A very big deal. C has been in widespread use for 40 years now, and Java for almost 20. You could switch a language every five years or so, but that means that you're not in "mainstream software development" but in some kind of Silicon Valley startup (a tiny minority among software developers). Mainstream software developers don't switch languages every five years, and in most case, not even every decade, so they'd better get the language right.
But what makes a programming language right? That is a big question. Obviously, adoption, which is also a result of marketing, is a major factor regardless of the language's intrinsic merits. Also, you must consider your domain. Ruby is great for short-lived projects; Java is great for big, complex projects with dozens or hundreds of developers.
But assuming you've taken all that into account, making a switch better be really justified. The problem with the article, I think, is it focuses on specific language features (effects, delegation, etc.), which is what got Scala into trouble (IMO) in the first place.
When thinking about a new programming language, especially one not intended for research but for widespread adoption, this is not the way to go. I believe we should start by thinking what are the big problems with software developments, and how we can address them with a new language – one that does not simply offer this or that convenient feature, but gives a really big advantage, one that merits a switch. Java has done it with a GC for a C++-like language, and to a lesser degree, with threads. Clojure and Erlang address the issue of state - Erlang because of fault-tolerance, and Clojure (mostly) because of concurrency.
On the other hand, some languages, like Ruby, focus on "developer productivity", which often means getting to working, useful code quickly, while maintaining good readability. This is, no doubt, important (for some domains much more so than others), but is this a major problem of software development today?
Also, the article talks a lot about type safety. But type safety is language feature which is a means to an end. That end can be project maintenance/manageability, and arguably more correct code. But are there other ways of achieving this goal? I'm not saying there are, I'm just saying we should start by studying the problem, not examining particular solutions. Every language feature must be a part of solving a big problem; big enough to justify switching languages. After all, that's is a big deal so we better get it right. So, what big problem are you trying to solve?