That "perfectly capable mechanism" is one-off JS glue code, which is so cumbersome that approximately nobody actually uses it even though it's been an option for at least 6 years. It would be silly to mistake that for a satisfactory solution.
From my (outsider) perspective, I think the main roadblock atm is standardizing the component model, which would open the door to WIT translations for all the web APIs, which would then allow browsers to implement support for those worlds into browser engines directly, perhaps with some JS pollyfill during the transition. Some people really don't like how slowly component model standardization has progressed, hence all the various glue solutions, but the component model is basically just the best glue solution and it's important to get it right for all the various languages and environments they want to support.
I think maybe you misunderstood what I meant. When I said "perfectly capable mechanism", I meant building the app in JS/TS and leveraging Wasm for additional functionality in your language of choice. I'm also not sure if the "one-off JS glue code" you're referring to is the JS file that languages like Go or tools like Emscripten spit out to get Wasm to work with your app, or the WebAssembly Web API specifically. I would agree that the former is a bit of a dumpster fire.
From my (outsider) perspective, I think the main roadblock atm is standardizing the component model, which would open the door to WIT translations for all the web APIs, which would then allow browsers to implement support for those worlds into browser engines directly, perhaps with some JS pollyfill during the transition. Some people really don't like how slowly component model standardization has progressed, hence all the various glue solutions, but the component model is basically just the best glue solution and it's important to get it right for all the various languages and environments they want to support.