I think you’re right that this would be fairly easy from an implementation standpoint, but there are two main reasons why we don’t want to move forward without careful consideration of the full problem space:
1. If we _simply_ add a flag that allows module resolution to work with `.ts` files, it will 100% contribute to the misconception that TypeScript does, can, or should emit JS files with the transformation `import "./foo.ts"` → `import "./foo.js"`. We already have angry mobs demanding that this happen for `import "./foo"` → `import "./foo.js"` so if we allowed `.ts` extensions on there without it being very clear what use cases it is intended to serve, it would just pour fuel on that fire.
2. Such a flag would look like a gift to Deno users, but it would actually be woefully incomplete for them. There are obviously a lot of other parts of module resolution that are either specific to Deno or shared between Deno and the browser that we don’t currently support, and I think those users would be confused and disappointed that we stopped so far short of proper support for these things.
Don’t get me wrong, I want us to solve all of these problems, but we’re still in the phase where we’re trying to develop a thorough understanding of all the different reasons people want this and what the existing solutions are.