All bytecode is sandboxed by definition -- the VM decides which operations it delegates to the system. It is possible (and common!) to use JVM bytecode in a VM that restricts access to the underlying system, and in fact one of the original core use cases for Java (applets) relied on this functionality.

The difference between WASM and JVM is that WASM was designed to be both (1) a compilation target for memory-unsafe languages like C, and (2) have verifiable control flow so it's easier to write a provably-secure JIT.

  > Because it's sandboxed, you can use it without a container. I think
  > that's what you don't seem to undestand.

You don't seem to understand what a container is, or what a sandbox is.

The reason to deploy software as a container image (instead of a standalone binary) is that a container image contains a full chroot, including auxiliary files that aren't embedded into the main binary. Whether the binary is native machine code or WASM doesn't matter -- the tradeoffs of bundling everything into one binary vs placing them on disk are the same regardless of executable format.

The reason to run a sandbox is to restrict which system resources a process can access or interfere with. You can sandbox a process whether or not it runs in a container.