WebAssembly expands on the ability to do client-side stuff and makes it more accessible, so my fear is that it will make it more common.

That's pretty much the entire difference. It's a difference of degree more than of kind. As I said, Javascript is making much of the web inaccessible to me, and WebAssembly, if it becomes popular, will only accelerate this loss.

I wonder how feasible a rendering proxy would be. It would run the JS in a simulated browser environment and return the HTML.

Interactivity would be tricky, but static HTML is better than a blank page.

Edit: Found something very similar, but it targets legacy browsers using clickable image maps rather than privacy/security.

https://github.com/tenox7/wrp

WebAssembly adds new functionality to the browser runtime environment that isn't available to regular JavaScript. It was originally 1:1 with asm.js/JS but that stopped being true relatively quick.

It's faster. That's literally it. There aren't any new I/O facilities.

A few examples of things it adds that are not widely available in JS (if at all, or requiring awkward hacks/hints in JS), off the top of my head:

int64

uint32

popcnt

copysign

reinterpret_cast equivalent (the js hack for this is abysmal)

pthreads

SIMD

AOT compilation

To be fair, it's been a while since I was last one of the authors of the webassembly spec, so I could be missing some things.

Could ads be served with web assembly?

Yes, though I don't know if it makes sense to do it for any reason other than hiding from ad blockers.

Well, for some it is the only reason needed...

WebAssembly allows allocation of memory and exposes a huge threat surface. We can't even protect the current APIs and these are being exploited by sovereign nations to oppress people like the Uyghurs. How about we focus on making the sandboxes stronger instead of building out things like WebGL and WebAssembly.