I'm saying rooting a machine to the point that it can customize an arbitrary USB key plugged in by the legitimate operator of the machine is impractical.
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.
Which gets back to the premise that monolithic kernels enforcing user privs is an outmoded form of security. Re-purpose the kernels as feature sets under an isolating hypervisor and security begins to look realistic.
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.
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.
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.
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.
If the email domain is untrusted, then create an untrusted Qubes vm for it. I could even create one vm for each role, plus one archival non-networked vm to store info, and even if the archival vm were compromised there's nothing it can really do except try to erase the data in that one vm. Securely copying between the vms is point-and-click (easier, in fact, than between user sandboxes on a regular system) or scriptable... one only needs to consider how risky the source and formats are to the destination vm. If there is a need to sanitize the info, its easy to do so in a Disposable vm (right now Qubes can sanitize pdf files, and other formats are expected). The only unintuitive caveat in such a virtualized setup is that sensitive asymmetric encryption (operations that use the private key) has to occur while untrusted VMs are not running in order to avoid side-channel attacks.