You could also reimplement some QoL features like E2E search by building a local index of seen cleartext messages, or perform spam filtering via local NLP models—though in my experience, I never saw any encrypted spam. Threading UI might use a cleartext copy, or instead of Thunderbird's "Subject: ...", it could use a random UUID while preserving cleartext "RE: " patterns.
PGP is a very simple standard and could have become the default if not for some unfortunate client UX. If a major mail client automatically imported or generated a key on first install, required the user to write down a BIP-style mnemonic for private key recovery (PGP private key containers are quite large, so this might rely on symmetrically encrypting a provider-side backup), and attached the public key to every outgoing email—enabling end-to-end encryption automatically, with trust established on first use—I’d expect that a quarter of all human email traffic could have instantly become secure, eliminating decades of complexity built to sustain the illusion of trusted parties. A provider offerring this UX within an interoperable standard could be the only push it needs.
You might object to TOFU as suboptimal, but it has been the standard in many encrypted messaging systems: Signal, for instance, uses key servers to distribute keys and relies on users to verify shared secrets out-of-channel, as does WhatsApp. If this simple manual verification UX could be integrated with Web of Trust, it could automatically vouch for the user, showing a reference path for each of your contacts. Even without that, it is better to accept a one-time risk of key exchange compromise than to face the continuous possibility of eavesdropping.