I cannot speak for the parent, but the difference for me is this: Matz wrote Ruby, for instance, because he felt that Perl lacked some features/capabilities that he wanted. This is good, and from this perspective, I have no complaints. Now, if Matz wrote Ruby to compile down to Perl, then it becomes an issue. At that point, Ruby wouldn't really be a new language, but just a Bandaid to hide the weaknesses and blemishes of Perl, for instance. Fundamentally, I would still be writing Perl, and that, for me, is where it becomes an issue, because I really haven't solved anything. I've just disguised it.

My opinion on the matter is that Javascript sucks. We all know it sucks too, which is why things like Elm, CoffeeScript, ClojureScript, TypeScript, BuckleScript, Scala.js, etc. exist. We want to fix Javascript because we understand that it sucks; therefore, we tend to embrace these various attempts to make it less stupid. The solution to the problem, in my mind, isn't yet another Javascript transpiler though, but rather native support for superior languages.

I'd like to see an API built into browsers to make them language agnostic. I think that would go a long way towards making web programming less lame. It may also give us a chance to clean up the DOM.

Our bearded forefathers wrote C because assembly had some issues. They still compile to assembly.

Haskell compiled to C for the longest time (and quite a few other compilers use that trick). That didn't make Haskell a bandaid around C, did it?

WebAssembly is a work in progress. I think they had their first release some time ago, but I don't know how long it will be before it's safe for languages to target it for compilation.

Language-agnostic browsers are the perfect solution. Transpilers are a good-enough solution. And as they say, 'The perfect is the enemy of the good enough'.