Spectre seems pretty hard to exploit in practice judging by the almost complete lack of observations in the wild (lots of PoCs you read about, but most won't work with standard mitigations enabled, and I haven't heard of any actual reports of usages beyond PoC toys, but I expect somebody to point to one shortly, of course :-P). Also, spectre is vulnerable to all kinds of mitigations, which vary and are in use, and change - all of which leaves a system vulnerable, but makes the engineering challenge of an exploit greater, and less transferable between systems. And not just the mitigations are varied, the exploit themselves may need to take into account CPU trivia; not every CPU leaks the same way.

But even supposing you pull all that off - spectre needs not just some entropy leakage, but also a way to put that entropy in context. Knowing a few random bits in some other processes memory space won't do you much good; you'll need to know something about how that process is working to interpret those bits and target the slow leakage, which is again pretty situational.

Finally, you need some way to check for indirect behavior changes, and typically that means timers. Those aren't directly available in WASM, and aren't as easy to replicate using other means as in a normal process; e.g. wasm doesn't even have fully capable shared-memory threads for exactly this reason (there's a proposal, and chrome feature flag, so you can play with it, but that's it); and other tricks to get reliable timers like via SharedArrayBuffer have been tweaked to avoid attack surface. But note: that's the case for WASM, but not for a classic OS program, even one running in a VM.

I'm not sure how much of a threat spectre is in practice, but clearly WASM is aware of it and avoiding features that would increase exposure, even very valuable stuff like threads.