Do you have any other frameworks in mind? Ones that easily and concisely hook into the DOM APIs provided by browsers? One that hot reloads in dev? Or maybe just accomplishes even a handful of the 11 targets listed at the beginning of the article?
Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.
This ideal framework would probably work in an ideal browser, without the DOM. Doug Crockford put it nicely, today's browsers are a "vast source of incompatibility, pain and misery".
Perhaps you're right, there may not be one. However, I think the point the OP is trying to make is that JavaScript is a shitty language and it would be better to invest some effort in replacing it with something better than to continuously try to "fix" all its inherent shitty-ness over and over again to little avail. Sure, JavaScript isn't as shitty today as it was 10 years ago, but it still isn't a well-thought-out, well-designed, or consistent language.
For examples of JavaScript's shitty-ness, I'd point to its various function declaration styles and their disparate effects on the code you write, its wishy-washy scoping, namespacing, the number type's precision problem, NaN being a number type, the ambiguity of this, just to name a few.
FWIW, there's Dart, but at the end of the day it's still just JS. This isnt to argue your point either, but one possible answer to the question(s) you bring up.
Here's my reason, rooted in practicality and not taste: For me, an ideal app framework would cover both web and native apps. All the major native app platforms rely at least partly on AOT compilation. Android, in particular, is based on a runtime that resembles the JVM at the API level and takes JVM bytecode as input at build time. So for me, the ideal app framework would be in a language that's amenable to compiling ahead of time to efficient JVM bytecode, as well as efficient JavaScript and, for good measure, efficient native code for iOS and Windows.
I think Kotlin is becoming a good choice for these criteria. If you want to follow Mr. Harris's framework as compiler approach, Scala may also be a good choice, because of all the compile-time metaprogramming facilities it has. I don't know how Scala Native stacks up beside Kotlin Native, though, and I've read that Scala 2.12 requires Java 8, so that's probably not a good choice for downlevel Android support.
Because I don't know of any. Except maybe the new Rust framework, Yew. Which seems very interesting.