All those new ideas in language design, are exactly that: new and unproven (like the Hindley-Milner type system, which, while quite old already, has not been proven to be a major strength, and it is certainly complicated, esp. its undecipherable error messages).
"Languages from 1995" (I don't know why you picked that specific year; some very successful languages are much, much older) have been used to build really good software, while "new" languages (Heskell, 1990; OCaml, 1996; Scala, 2003) have not proven to completely change software quality in a way just justifies their arguably less intuitive (if only culturally) designs.
Where are all the bug-free Haskell operating systems, drivers and embedded controllers? Where are the OCaml scalable severs? Where are all the Scala complex enterprise apps? I'm not saying there isn't any really good software written in those languages, but not nearly enough to prove a significant qualitative advantage.
On the other hand, when Java came out in 1995, it took maybe 5 years for pretty much the entire software world to adopt it, and it wasn't just marketing: its advantages were palpable and immediately apparent. I think (though I'm not sure), that C and later C++'s adoption was about as fast. If 25 year old languages like Haskell, and even 10 year-old languages like Scala, haven't shown such an immediate and enthusiastic widespread adoption, maybe their advantages aren't that extreme. Instead of those languages' designers sitting mind-boggled, maybe they should think long and hard about what it is that they're solving exactly and how important it really is.
I think the problems tackled by more "modern" languages are either not important enough, or their solution is far from optimal. For example, it is quite possible that a good type system could help produce good software faster (though it isn't certain either), but that this type system is Hindley-Milner seems unlikely at this point. Pluggable type systems (like the ones recently introduced to that 1995 language, and, I believe, also supported by Kotlin) might actually be a better way to go forward. I also think that some more important advances in programming languages have come not from PL researchers, but from developers (Java, Erlang, Clojure).