Earlier quoted context omitted.
Because TSC isn't your bundler. It's job is different from a bundler. A bundler runs under the assumption that everything you import it has to find and handle. Typescript only needs to find a definition for an import. Typescript may have a complete view of a single project, in which case yes, it should know what file type it is emitting in that project , but then it has to track "in project" imports differently from…
I realise it’s not trivial, but it’s really hard to believe it’s that difficult! When I look at the multiple(!) issues on TS GitHub asking “please, can we just import .ts files with a .ts extension? That would make life a lot easier”, the comments from the developers pushing back on it aren’t about Node integration issues, they’re about the unshakable principle that TS must never rewrite syntactically valid JavaScrip…
Which is starting to be a very useful principle of Typescript. Typescript knows that today it is not your bundler and tries to leave almost all rewriting to your bundler. That leaves bundlers able to strip types without even needing a direct dependency on Typescript. This is why tools like swc and esbuild written entirely in other languages now type strip as well.
This is also why the Typescript team has been a proponent for a proposal to add type stripping (or something like it) to the entire web platform. (There's a Stage 1 proposal in TC-39's process.)
You may not find that useful, but there's a growing ecosystem around "Typescript is just for types, not also for deeper transpilation". It is not just TS developer being "high and mighty" in the face of things you think they could make the developer experience easier on.