WASM isn't really a replacement for JVM bytecode. It's not like you can take a random JAR and convert it to WASM. Last I checked, WASM doesn't even support GCd languages at all, and at any rate the whole insight that makes GraalVM unique and a big deal is that universal bytecodes are a poor choice for making fast polyglot VMs. The JVM world was doing that long before WASM was even a twinkle in Google's eye, with invokedynamic and other initiatives, and it kinda works. JRuby+indy is a lot faster than MRI. But, there's a lot of compromises involved.
Truffle is interesting because it says, no, we should not be trying to compile everything to a universal bytecode. Instead, we should JIT compile the source code directly, using the JVM as a runtime library but bypassing the bytecode layer. The language semantics can be expressed much more clearly, without needing to contort things to make them look like Java, whilst still benefiting from the JVM's core feature set.
So really I'd ask it the other way around. If it weren't for the politics of the browser world and the monolithic "Chrome is the OS" approach, would WASM be competitive? Because the Graal team already proved you can run lots of different languages at relatively insane speeds using partial evaluation and bypassing bytecode. The WASM world has proven it can run C++ and Rust at slower speeds than normal, which isn't particularly unexpected. If Chrome and Safari shipped GraalVM accessible via <script> tags, how many people would care about WASM? Remember that you can run WASM and LLVM bitcode on top of GraalVM too, it's not just about textual languages.
Arguably, if you wanted to give the web an instant free upgrade that'd make many developers rejoice, integrating Graal into Chrome would be an overnight way to do it. Python, Ruby, JVM bytecode and any other language you want at V8 like speeds, in a script tag? It's technically possible, it's just not politically possible.