There are some good points in there, and, while I don't want to provide a definitive rebuttal, I think it is worth mentioning how close PGP is to something that can be recommended. Let me respond to the issues one by one:

> If messages can be sent in plaintext, they will be sent in plaintext.

This is actually perhaps the strongest argument. If I'm steelmanning it correctly, it says that any system which tries to be backwards compatible with an insecure protocol is likely to result in some messages being unencrypted when they're not supposed to, either by accident, or due to an attack.

It's true that by introducing an entirely new, backwards incompatible protocol, this entire class of problems can be almost eliminated. There is still, of course, the problem that someone copy-pastes text from a secure context to an insecure context, but I agree that there is a meaningful reduction of risk being offered here.

However, it is worth comparing this situation to the web ecosystem. The fact is, browsers still support both HTTP and HTTPS, and a lot of work has been done on protocols, and implementations, and UX to stop downgrade attacks from happening. To avoid this problem, we could have defined HTTP to be the legacy web, and come up with an entirely new protocol (perhaps one where a benevolent dictator provides the only accepted client and server implementations), but I'm glad we didn't go down that route.

> Metadata is as important as content, and email leaks it.

While the most popular email encryption tool doesn't encrypt subject lines, Delta Chat, for example[0], does. That's therefore not an argument against encrypted email as it against using clients that aren't as good as Delta Chat. However, your point about backwards compatibility is still relevant here.

I suppose the analogous scenario is that with HTTPS we know whether the connection to the server is encrypted by looking at the URL (or the padlock, or other clues that users don't really follow). However, until quite recently there was still the issue that a request over HTTPS could pull in sub-resources that weren't encrypted, which feels somewhat equivalent to someone accessing their Delta Chat inbox in a separate client that doesn't use PGP.

As for other metadata, it would be possible for email providers to implement a type of anonymous remailer, where the sending server hides the sender address, and the recipient server decrypts an outer layer of encryption to find the intended recipient, but I admit that no providers currently offer such a service. If it were implemented, though, I think it could offer better security than centralised services, because the metadata could be split across different jurisdictions, removing the single point of failure.

> Every archived message will eventually leak.

This seems to be an argument that if you store sensitive documents on your computer, then the security of those documents is only as good as your at-rest encryption (and your ability to stop someone separating you from your computer when it is unlocked). You accept that recipients can configure their email clients to delete old messages stored on their computer, but then you seem to require that senders can delete their old messages on other people's computers, which doesn't seem like something any protocol can enforce.

(You also make a point here about how JavaScript sent from a server can't be made secure, because a server can send a different script next time you visit. That's true, unless the initial page of the web app is stored as a bookmarklet[1], or secured by a hashlink[2], which browsers currently don't support).

> Every long term secret will eventually leak.

Yes, it would be nice to have Perfect Forward Secrecy supported by PGP encrypted email. There has at least been some effort to advance that at the IETF in the past[3], and it's also being considered as part of the future development of Autocrypt.[4]

[0] https://delta.chat/pt/help#how-does-delta-chat-protect-my-me...

[1] https://news.ycombinator.com/item?id=17776456

[2] https://datatracker.ietf.org/doc/draft-sporny-hashlink/

[3] https://datatracker.ietf.org/doc/html/draft-brown-pgp-pfs-03

[4] https://autocrypt.org/next-steps.html#deletable-forward-secu...