You could make the same argument of anything but bytecode and even then some would debate if it's really running directly enough on modern CPUs. In the end it still remains that you have the time it takes to build your project in a given language and the runtime performance of the end result. Those remain very useful distinctions regardless of how many layers of indirection occur between source code and execution.
The difference here is that with Typescript, you're not really measuring Typescript's performance, but whatever your output language is. If transpile to Javascript, you're measuring that, if you output Wasm, you measure that, etc, and the result isn't really dictated by Typescript.
Transpiling isn't the only possibility to run TypeScript code, it's just the way to do it right now. A long time ago interpreting was the most common way to run JavaScript, now it's to JIT it, but you can also compile it straight to platform byte code or transpile it to C if you really want. That you could transpile JavaScript to C doesn't mean all ways of doing it would be equally performant though.
Transpiling in itself also doesn't remove the possibility of producing more optimized code, especially if the source has more information about the types. The official TypeScript compiler doesn't really do any of that right now (e.g. it won't remove a branch about how to handle a variable if its type equals a number even if it has the type information to know it can't have been set to one). Heck, it doesn't even (natively, you can always bolt this on yourself) support producing minified transpiled code to improve runtime parsing! In both examples it's not because transpilation prevents optimization though, it's just not done (or possibly worthwhile if TS only ever targets JS runtimes as JS JIT is extraordinarily good these days).
Not really in the case of TypeScript, because (with very small exceptions) when you “compile” TypeScript you are literally just removing the TypeScript, leaving plain JavaScript. It’s just type annotations; it doesn’t describe any runtime behavior at all.
That depends on both the target and the typescript features you use. In many cases, even when down leveling isn't involved, transpiled code can result in more than just stripping type info (particularly common in classes or things with helper functions). There's also nothing stopping a typescript compiler from optimizing transpiled (or directly compiled) code like any other compiler would, though the default typescript tools don't really go after any of that (or even produce a minified version itself using the additional type hints).
Agreed, at least usually right now (it doesn't have to be forever, which would probably be the most realistic way for TypeScript to make meaningful runtime gains). That does not preclude the possibility of producing more optimal JavaScript code for the runtime to consume. I give a couple examples of that in the other comments.
