> Suppose you want to use gpg to encrypt Gmail conversations. Your workflow is basically copy-pasting text into and out of a text editor and then attaching the ciphertext to the email and sending it.
If you're using the web browser. Gmail can use IMAP and so plenty of clients can encrypt the messages natively. There are Android apps (and probably IOS) that do this as well automatically.
The important thing here is that Gmail isn't the standard for email, and the more that you rely on commercial email companies to streamline encryption the more you'll be let down.
> Using GPG (correctly) is a colossal pain in the ass. In a lot of ways it reminds me of git: inconsistent and confusing UI/UX, obtuse documentation, footguns around every corner.
GPG doesn't have a UI/UX. GPG by itself refers to GnuPG which is a library and command line tool for generating, importing/exporting keys, signing, etc. The documentation is available on their website and follows industry standards in documentation, and also including man pages as well.
There is always improvements that can be made in terms of automation for users, but that is what Keybase does. There are also a plethora of third-party GPG tools that a large community of users are happy with and there is nothing stopping you from building your own.
> If you truly grok the internal mechanics, then {gpg,git} can be a good and productive tool. But that bar of grokking the internals is too high for casuals and so there's a plateau of adoption that's inevitable.
Can't you say the same about almost any piece of software. If you tried to understand the internals of almost any piece of software, it can be difficult to understand. Vim has its own scripting language. JavaScript has like 20 different implementations.
That is what the third-party tools are for, and many of them have made it very easy to use.