That's looking from the outside in but consider looking at it from the end-user (read: attacker's) viewpoint.
The lack of memory protections that wasm currently has such as the lack of read-only memory or memory randomizations or anything else you really can't run any code with any level of assurance that it won't be taken advantage of. Typically a software engineer doesn't have to think about someone being able to rewrite a function during run-time or a statically defined variable because those memory protections are in place. It simply isn't allowed. However in wasm land, if you have a function that is say 'func isAdmin()' for instance you'd expect to return true if the logic is correct but without memory protections an attacker can force it to return true every time. This is one of the pretty serious features missing in wasm currently.
wasm has separate address spaces for code and data, and wasm code does not even have read access to the code space, much less writing to it. The call stack is also completely isolated and not addressable. So how exactly would malicious code running in a wasm sandbox "rewrite a function"?
The lack of memory protections that wasm currently has such as the lack of read-only memory or memory randomizations or anything else you really can't run any code with any level of assurance that it won't be taken advantage of. Typically a software engineer doesn't have to think about someone being able to rewrite a function during run-time or a statically defined variable because those memory protections are in place. It simply isn't allowed. However in wasm land, if you have a function that is say 'func isAdmin()' for instance you'd expect to return true if the logic is correct but without memory protections an attacker can force it to return true every time. This is one of the pretty serious features missing in wasm currently.