The "running WASM on the server" use case is pretty fun and applies to whenever you want to execute untrusted user code and limit its capabilities / resources, e.g. for plugins. For example, we use it in Seafowl [1] for user-defined functions, so does ScyllaDB [2]. Cloudflare Workers [3] lets you deploy arbitrary WASM code at the edge and pay at high granularities just for the amount of time your function spends executing (e.g. 10ms is the limit for the free tier).
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).