The wasm paper covers these issues, and is short and pretty readable:
https://scholar.google.com/scholar?cluster=14979605902538775...
tl;dr security introduces a lot of design constraints that RISC V doesn't have.
section 2.3 on structured control flow:
WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form
intermediate form in a single pass.
Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons:
section 2.2:
Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory.
However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits.
https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v...
If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement.
Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.