Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance)

A few benefits why it is even useful in a server context:

You can distribute a single (small!) artifact and run it everywhere. On a developer machine, on Windows, on a x86 server, on an ARM server, ... Right now you have to build a separate Docker image for each architecture. And Docker is really a second class citizen on Windows.

Docker images have a huge dependency: an entire operating system syscall API and an entire userspace (with libraries, binaries, a file system, ...) The surface for a Wasm module is much smaller.

Building a Docker image is a somewhat redundant exercise of picking a base image, figuring out the dependencies, keeping it up to date, ... None of that should be necessary.

Security is another benefit. The vulnerability exposure of a Wasm module is much lower than that of an entire OS + userspace sandbox.

Wasm is designed around isolation. In addition, the interface types proposal + WASI is pushing capability based security that works by passing around capabilities, which is a pretty great model.

I outlined some more benefits here a few days ago: https://news.ycombinator.com/item?id=30020121&p=2#30020964