It’s true that a full blown VM is an excellent sandbox.

The usual situation is like what chrome or OpenSSH want:

- They want to be able to do dangerous things by design. Chrome wants to save downloads. Chrome wants to call rendering APIs. OpenSSH wants to pop a shell.

- They want to deal with untrusted inputs. Chrome downloads things off the internet and parses them. OpenSSH has a protocol that it parses.

So you want to split your process into two with privilege separation:

- one process has zero privileges and does the parsing of untrusted inputs.

- another process has high privilege but never deals with untrusted inputs.

And then the two processes have some carefully engineered IPC protocol for talking to one another.

Could you run the deprivileged process in a VM for maximum security? Yeah that’s one way to do it. But it’s cleaner to run it as a normal process, ask the OS to sandbox it (deprivilege it), and then have a local domain socket (or whatever) that the two processes can use to communicate.

If you used a VM for deprivileging then:

- There’d be more overhead. Chrome wants to do this per origin per tab. OpenSSH wants to do it per connection. Maybe a VM is too much

- You could put the whole browser into the VM but then you’d still need something outside it for saving files. And probably for talking to the GPU. You could run OpenSSH in the VM but then that defeats the purpose (you want to use it to pop a shell after all).

- You can use vsocks and other things to communicate between host and guest but it’s much more gross than the options available when using traditional process sandboxing

When it comes to VMs, most things are solved and have near native performance, but desktop graphics are not. Due to limitations in GPU architecture, you usually have to dedicate an entire GPU to the VM to have reasonable graphical acceleration. Qubes doesn't solve this either, IIRC the apps running in VMs are glued to the host with X11 forwarding without any acceleration support.