user doesn't want to download an app, since that has a lot of friction. Going to a url and waiting (even if the download time is the same) feels like there's less friction, and so this idea of shipping a blackbox is more desirable.
The only problem really is the jankiness of any non-browser controls. The user expects a good right-click context menu, keyboard navigation, scrolling, etc, which all would have to be implemented if you're compiling a native app into WASM. But if the app itself is just HTML+javascript, then shipping a WASM browser, then using that browser as the app layer solves all of those UX jankiness (since the user should not really be able to tell it's a WASM browser).
The idea is insidiouly bad for user freedom, but great for businesses like google (who wants to control the user space completely).
Your proposal, while feasible, turns this into a static linking affair. This comes with many risks, like becoming complacent and not updating the "inner browser" due to browser incompatibilities and bugs. It creates a giant mess of dependency update hell if you aren't regularly updating the webview.
At that point, you might as well ship a desktop app that does something similar and proxies ads through the first party server since it's probably less work.
You are right that it would work. I just don't know if going to such lengths is required to achieve the same thing.
A good counter is that a desktop app could be exploited to alter the behavior via reverse engineering. But a browser would show you the WASM as well, so I'm sure you could reverse engineer it and alter it with an extension like a traditional binary.
Maybe I'm missing something though - I'll admit that I'm an advocate of WASM but don't keep super up to date on all advancements.