Can't upvote this comment enough. I'm also currently in the process of creating a full featured WebGL game, and nothing is faster than simply using pure JavaScript there. Most people won't accept this, but when you ask them, those never actually tried creating a complex WebGL game.
These are totally fine most of the time. Typescript in particular looks like a good choice for game development.
Sometimes the language is less of a good choice. E.g. i did a small toy project in coffeescript about two years ago, and found to my horror, that if your function ended in a loop, it would return an array. Always. This isn't possible to accidentally do in the host language, so I'd say it is a bad fit (for game development, where you care about such things).
I believe that point is that JS always returns something for every object. Many users of JS just don't realize it. (I know I didn't till I started drinking the coffee flavored kool-aid)
This is probably as a result of CoffeeScript's Ruby-esque syntax and semantics. It does mean you can write some very clear and succinct code at times, but the tradeoff is that it can have unforeseen performance implications.
They don't add much overhead during runtime; most of the time there is zero overhead, or sometimes they can (theoretically, not sure if it's done in practice) produce more optimal code than a "literal translation".
It depends on the language. TypeScript is basically JavaScript with added bits. Unity compiles to JavaScript, but it does so through a crazy chain of C# -> CIL (via Mono) -> C++ (via il2cpp) -> JavaScript (via Emscripten). And then remember that your browser then converts that JavaScript to assembly. Holy convoluted toolchain, batman.