That said you can still setup sandboxing without Qubes.
Qubes is my daily driver by the way. My attempt of explaining it to a layman: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
You can be a victim of a random drive-by, you don't have to be a person on a "list".
I think it was worth it because even though we were a small boring company we received a fair share of drag-net style malware via the application channels.
Some of the attempts were pretty good also. I used to joke that the bad guys tailor their cover letters better than most real applicants. Which of course is a bit of a hyperbole, but there is a kernel of truth. It's not too hard to write a believable application letter that fits the archetypal IT position. Similar to not all fishing mails being full of spelling errors malicious application letters aren't either.
I don't know if we ever received a targeted attack, but I wouldn't know. I think bigger companies certainly will and I can only consider every HR department a high risk area.
"Not trusting modern software to be correct nor secure" is sufficient.
I do almost all my web browsing in disposable VMs with no access to interesting things like my password manager, email, SSH keys, etc. I also run JITless (disable Javascript JIT engine), because those are a common attack point on browsers.
If you compromise my browser from a random site, you get nothing of interest. Even if you pop the kernel. You still have to get through Xen to get to anything I consider of value.
It's all broken, all the way down. However, compromising a browser or kernel is still a lot easier than compromising a hypervisor. At least in terms of number of known exploits.
Qubes tends to make very limited use of the riskier parts of Xen anyway, though. A lot of the security notices for Xen don't apply to Qubes because of how they've configured things or what features they use.
Agree wrt your arguments; it's also why I write this in a browser in a VM that is not used for anything else than this sort of thing, and periodically I will roll back to a recent snap shot with a clean browser.
(I do not use Qubes, but I do like their work.)
Browser exploits are a thing, and reliably compromise systems. Apple just released a security update yesterday for "something in WebKit," and we see regular browser security updates.
The art of escaping browser sandboxes seems to exceed the art of building browser sandboxes. The Javascript JIT engine gains you a lot of attack surface, unfortunately (one of the reasons I run JITless with Javascript).
As for snaps, they're just containers - kernel separated. Unfortunately, I consider the value of that against actively malicious code to be "about zero" - local root/kernel exploits are fairly cheap. Containers (so snaps) are great for convenience - if you want to run code you trust without worrying about dependencies, this is fine. They're not fine if you want to isolate things you don't trust - such as a browser from "everything else."
Qubes gives you a much harder boundary around your VMs than containers and sandboxes do.
It's not unthinkable, as Xen is huge, at hundreds of kLoCs. But there's an effort[0] to make a Qubes that uses seL4 in place of Xen.
But it's bad enough if any do. (some do affect Qubes)
It is an architectural problem.
SeL4 is a good replacement, with excellent performance and strong formal proofs.