Right now, sure.

But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.

To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:

1. Does the full compilation to JS, and that's what gets deployed.

or

2. Just lints the file, and has the original TS file deployed.

Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.

There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.

Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.

I'm not seeing any downside here.