The web is anything but small/lightweight and WASM requires a full blown JIT a la V8 to get good performance, so WASM being "small" (relative to what?) seems hardly a benefit.
JVMs are sandboxed and verifiable too, not sure what use a fallback to stock JS is but you can run a JVM in JS (look at TeaVM), it's way easier to emit bytecode for almost any modern language than WASM simply because JVMs do garbage collection for you and it's not really any easier to build tooling for WASM than any other VM.
In the end the main reason to do WASM over other VMs is that this way Mozilla/Chrome guys get to own it, instead of a competing firm.
WASM doesn't need a JIT, it needs a compiler. Unlike a standard JIT, you don't need decompilation and instrumentation. WASM is also designed so that browsers can reuse their JS JIT as a WASM compiler. Even from a JIT perspective, the difference between a lightweight JIT (eg. LuaJIT) and the heavyweight stuff used for JS is huge, and then the gap between JS JITs and Graal is a second such chasm. This equivalence is a false one.
Graal is not designed to be verifiable the way WASM is. We learnt enough from applets to not repeat that mistake.
GC is a distraction; WASM's opt-in is much better than Graal's by-default for use as a general compilation target.
WASM wasn't chosen disingenuously. Nothing else filled the role. If something did they would have used that instead.
JVMs are sandboxed and verifiable too, not sure what use a fallback to stock JS is but you can run a JVM in JS (look at TeaVM), it's way easier to emit bytecode for almost any modern language than WASM simply because JVMs do garbage collection for you and it's not really any easier to build tooling for WASM than any other VM.
In the end the main reason to do WASM over other VMs is that this way Mozilla/Chrome guys get to own it, instead of a competing firm.