Except that privilege escalation attacks against these multi-decade-old systems appear year after year. A well-funded state attacker (OP is about activists, after all) would certainly have some at their disposal.
All code has bugs. Xen has bugs. Qubes has bugs. And yes, OSes have bugs, although Linux local privilege escalation bugs are not an everyday occurrence, and OpenBSD bugs are very rare. You can't handwave a 0-day privilege escalation vulnerability into existence and claim that there are no 0-day privilege escalation vulnerabilities in Xen.
Re: CD-R, lets assume I use an optical disk to move a quantity of email messages from a networked/untrusted machine to an airgapped one (both conventional architecture). If I export as .eml files, I have to archive them before burning them. So, over and above the risk from nasty email attachments, there is the risk the untrusted machine could use malformed email or archive format to perform an exploit. If you think that's far-fetched, consider how much more complex email and archive formats are compared to the .lnk files that were recently discovered as an NSA exploit.
tar is pretty solid, actually, but, if you don't like it, make up your own trivial archive format (it's not hard), or don't use it and follow a one-disk-per-message protocol. And don't use a filesystem. dd if=email.eml of=/dev/cdrw (approximately), then dd if=/dev/cdrom of=email.eml
Even so, the untrusted networked system could take a chance that you have automounting enabled or that you will inadvertently do something to mount a volume... it could write a malformed filesystem to the disc anyway.
User error could happen with any system. You're really stretching here.
Once an air-gapped system is compromised, it can alter the hard drive firmware to store passwords and keys in a format/cipher readable by the attacker who can later break-in to the premises and steal/confiscate the computer. In a Qubes non-networked vm, there is no out-of-band way to communicate or store info, and a compromised vm wouldn't have access to the disc encryption password in any case.
Where did I ever say any of these computers had hard discs? And of course there's an out-of-band way to store info. Just use a magical vulnerability in Xen I made up to write it to another VM's permanent storage.
What you described #s 1-5 sounds much more complicated than using email in Qubes. And presumably this covers only email for one type of role (work, personal, etc); Covering all the roles means using many additional computers and burning many discs, and each role needs its own disc encryption passphrase.
I have no idea where you're getting that disc encryption has anything to do with anything here, and, no, you could definitely use the same three computers for all your emails. If you find burning discs to be too cumbersome, use floppy disc drivers or Zip drives or something, but it's really not that bad, especially if you don't bother to fixate.
This whole notion you have that "the operating system is insecure so let's put another layer on top of it" is just silly. If you make Xen your operating system, then Xen is your operating system. If you want a secure operating system with no privilege escalation, then that's what you need. Using a hypervisor doesn't magically make security vulnerabilities go away. There have and will be attacks against Xen, against Qubes, and against any other complex pieces of software you create. You want a secure OS, then you need a dead-simple OS written with security in mind. True security comes from simplicity, not complexity.
The one thing I think you're right about is that modern OSes are too complex to provide extreme levels of security. OpenBSD is the best, but even it is a quite complex piece of software. A braindead-simple POSIX-like OS kernel prizing security above all other values may have its uses. It could use generic hardware drivers for the hard disk and display adapter (VESA). Ethernet would be a problem but maybe there's a standard for USB Ethernet adapters? Wayland for the graphics API instead of X, braindead-simple written-from-scratch TCP stack, you get the idea. I'll have to make that when I have time. It shouldn't be too hard.
