Brainstorms of a (mere) hobbyist:
Some might reason that that yields additional hardening to traditional TLS-enabled webmail applications.
On the other hand, that is more architectural design and work shifted away from the endpoints (and wasted, complex efforts with no added benefit if improperly implemented by the provider).
The provider can serve key escrow and still have the end-user application perform the encryption, which may or may not technically qualify. It certainly wouldn't fly without skepticism in a popular service/standard.
I haven't looked into it deeply enough to present a confident statement either way.
> Or they could let their provider hold onto a copy of the private key
Then the key is no longer private. The idea of a private key is not to share or distribute it.
Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all.
Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.
They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated.
The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with.
Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.
The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key.
Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails.
But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.