To simplify my position as much as I can: I'm imagining a world where a babel-ish set of APIs becomes a core part of your web browser.
Syntax transformations then become scripts which target the browser APIs for code transformation. A transform to strip Typescript types would just be a preprocessing script that the browser could be directed to load.
TC39 could then approve a new syntax-sugar feature and it could ship to all browsers overnight just by loading a new script for the universal preprocessor engine! JS0/JSSugar solved. It's great for browser implementers because it frees them from playing continual catch-up and instead allows them to focus on their engineering priorities. It's great for authors of websites because everyone writing Ecmascript can start to use new features they day after their transformation scripts are approved/shipped by TC39, secure in the knowledge that all browsers will support them! This would even be amazing for Typecsript, as the TS team would be able satisfy the same conflicting constraints: they could promise their users build-less use, while also being able to continue to iterate on their language and ship new syntaxes without losing buildlessness
The main problem is that so far nobody has proposed a set of APIs that could be stable, performant, and well-encapsulated enough to make this plausible -- once shipped these APIs will would have about as much room for breaking changes as the HTML DOM. Babel's APIs are not fit for purpose, but BABLRs APIs should be.