You are referring to the example exploit in section 5.3, right? Please note that this example is for a standalone VM, not inside the browser (where JavaScript programs -- and by extension, WebAssembly modules -- do not have direct access to the filesystem).

Whether that exploit is more or less concerning than the browser and Node.js examples, I think is hard to answer in general without additional qualifications. If the standalone VM uses fine-grained capabilities (e.g., libpreopen) or is sandboxed, then changing the file that is being written to might be possible inside WebAssembly memory but access could be blocked by the VM.