Indeed, all code has bugs. Its a question of who/what is using the least amount of code necessary to provide a security mechanism. That's what reducing the attack surface is really about.
From a security standpoint, Qubes would by definition have very few-to-no additional bugs above what exist in Xen. OTOH, as I have implied, a Linux or Windows kernel + supporting libraries and also the firmware for USB controllers and NICs are immense compared to Xen plus a couple Qubes drivers (there is more to Qubes code, but only a small bit is critical to security).
I'm just pointing out that air-gapping does rely on the good behavior of an awful lot of code at its security perimeters. And it is TWO or more perimeters, not one, because you are putting some faith in the networked machine(s) being well-behaved as well.
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.
And why should a user be burdened with a detail like controlling automount behavior? Its exactly the kind of thing you see in the papers when people are hacked. And it raises the question of how much of a tireless control freak you have to be to make a security schema work.
Its much safer to have a core domain that simply doesn't mount any extra volumes and is cut off from the network. One can quickly dispatch a disposable vm to look at the contents of a drive or copy something.
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?
LOL! OK you 'win' that one. Let's do without mass 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.
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.
As I pointed out, Xen is tiny. Its not being layered on top of anything.
Hypervisors vary in their security focus; Most are designed to re-purpose a CPU security mechanism as a way to conveniently maximize hardware usage or run alternative OSes. They don't care much about security, especially on the desktop where they focus on convenience alone. They expose graphics, audio, clipboard, etc. in ways that practically define the category of vm-breakout exploits.
Xen cares very much about security on the server, and Qubes adds what is necessary to extend that to the desktop by properly virtualizing the graphics subsystem along with everything else, for example.
True security comes from simplicity, not complexity.
I agree -- However, functionality comes from complexity. So the solution becomes using simple security mechanisms to manage the de-privileged complexity.
It has been fun arguing over two different isolation mechanisms. Air-gapping is not often discussed in detail, and it would be nice to see sites like