In addition, you can limit the amount of instructions [4] a certain subroutine is allowed to use up before halting.
Also, WASM subroutines can only call out to functions (including system calls) that you allow them to (they're sandboxed otherwise). By default, they can't open files / print to stdout, unless the module can import the relevant functions (which WASI [5] provides).
[1] https://www.splitgraph.com/docs/seafowl/guides/custom-udf-wa...
[2] https://www.scylladb.com/2022/04/14/wasmtime/
[3] https://blog.cloudflare.com/announcing-wasi-on-workers/
[4] https://docs.wasmtime.dev/api/wasmtime/trait.ResourceLimiter...
You expose some apis in the wasm runtime and plug-in developers only have to target the wasm runtime.
Another use case, imagine a single program mixing and matching many different languages because they all compile up WASM as a universal format. This already happens in the frontend web with so called microfrontends which basically let you write various components in React, Vue, Angular etc and it all compiles down to JS.
It provides capability based security, something Windows, Linux, etc. all lack.
Edge computing/serverless
True polyglot environments (unlike Graal)
Really anywhere you want AOT/JIT compiled code running fast in a sandbox.