Using a language that compiles to javascript is still using javascript, though.
I think what the author meant to say is "you can pretend you're not writing javascript, even though you really are."
But once you compile that better, safer, saner language into the untyped, dynamic, poorly designed mess that is javascript, and run it in the volatile environment of a browser, it's still javascript running in a browser.
That's like saying if you compile C++ to Intel x86 assembler, you're still programming in assembler. JavaScript is the "assembly language" of the web; compiling (transpiling) to it is not directly programming in it.
Now, you're half-right in that you may occasionally need to drop into JavaScript to do some "low level" things. This is no different from C++, where you may occasionally need to drop into x86 assembler to do some low level things, such as local speed optimization, or hitting memory-mapped registers.
In both cases, you're programming at a higher level using safer and more sophisticated abstractions.
It's similar, but not the same. Moving from C++ to assembler is dropping from a high level of abstraction to a low level of abstraction. Moving from, say, Python to Javascript is just switching one high level language for another - there is no "lower level." You could just as well save the trouble of the second language and run a type checker or linter on javascript code itself and wind up with the same degree of "safety", such as it is.
As you pointed out yourself, JavaScript is a poorly designed mess. It may be a "high level" language, but it's also dangerous to use. None of the linters do a perfect job of ferreting out all the problems. In other words, JavaScript will never be 100 per cent "safe" to use. Treating it as a lower level of abstraction doesn't harm us. It simply gives us a foundation for using better languages, and that has to be a Good Thing.
The article gives 8 examples of transpiled languages, 4 dynamically typed and 4 statically typed. There's no real preference for static typing, and in fact I'm a big fan of dynamic typing.
However, there's a difference between a strongly typed dynamic language and a weakly typed dynamic language. JavaScript is an example of the latter and it's done very badly (eg, inconsistent semantics). The lack of discipline makes it difficult to write safe, reliable software. Thus, JavaScript is ill-suited for serious software engineering.
MoD411 is referring to "loose typing and freewheeling coercions." This is not about "type safety." It's about having a predictable and reasonable binding of types. JavaScript is very sloppy in this respect, especially with regards to the underlying semantics.
I find that the easiest and most reliable way to avoid having to deal with JavaScript is to simply avoid doing anything related to the web. Life is better that way.
That's pretty hard to do, since nearly everything in IT today is web-related: enterprise client/server applications; mobile apps; the burgeoning Internet of Things (IoT).
...with full awareness of the irony involved, I will note that I actually did have to write some JavaScript code last year, for work - not because I was doing anything related to the web, but because I was building some test cases for our static-analysis tool. So even in this nearly web-free paradise, JavaScript still managed to wriggle in.
There's no doubt this policy has created some interesting challenges for my career path, but I still think it was the right decision. It reduced the number while increasing the quality of the available work options.
I think what the author meant to say is "you can pretend you're not writing javascript, even though you really are."
But once you compile that better, safer, saner language into the untyped, dynamic, poorly designed mess that is javascript, and run it in the volatile environment of a browser, it's still javascript running in a browser.