Can you explain why atleast one of them is bad in WASM in your own words? Why be concerned? There are not really that many capabilities inside the WASM program that can be exploited and its hard to imagine a realistic example. An example that paper gave is doing document.write from WASM with unsantized strings but that is bad practice even in Javascript.
The bounds checking story is only on the external limits of linear memory segments.
If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker.
Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode.
It is only yet another one since various others that came and went since UNCOL became an idea.
How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.