If you're adding all the complexity that comes with using a language that must first be compiled to ECMAScript anyway, then why would you pick a language that's essentially ECMAScript with fancier clothes?
The build chain complexity tax is already paid. Now you can go for the best language the ecosystem offers. Half-measures seem wasteful.
(This was at least how I reasoned when I went for F#-to-ES.)
I would be very very cautious about this line of reasoning. It can work for certain situations, but there are enough tradeoffs and exceptions that I am hesitant to recommend this as a general rule of thumb.
The ability to incrementalize risk (JS code snippets on the web just work, the compilation target is trivial to deduce, runtime characteristics do not change, no need to write wrapper code to consume npm packages, etc) instead of taking a lump sum hit to your novelty budget is valuable. Not always overwhelmingly so, but enough to give me pause.
If you're adding all the complexity that comes with using a language that must first be compiled to ECMAScript anyway, then why would you pick a language that's essentially ECMAScript with fancier clothes?
The build chain complexity tax is already paid. Now you can go for the best language the ecosystem offers. Half-measures seem wasteful.
(This was at least how I reasoned when I went for F#-to-ES.)