Just as much as knowing how git works under the hood doesn't necessarily make you great at managing branches in git. More often than not it's way easier to just go with a sort of ready-made recipe, so that your workflow would be easily accepted by the industry; rather than read the doc.

For me it culminates in the way gpg feels really opinionated about key management (with keyrings). Way too often (in relative terms) I end up creating a temp dir, setting GPGHOME, then setting some permissions to quiet up gpg, then importing the keys, then actually doing the thing I wanted, and finally cleaning up[1]. I have no doubt the keyring design works wonderfully for gpgs author(s), but for a tool that should really be more generic than that it feels less ideal.

gpg being as monolithic as it is probably is the fundamental problem here which, in addition to making it unnecessarily cumbersome to use in some cases, also makes it more difficult to learn piecewise (imo).

[1] For one example, see my comment here: https://github.com/keybase/keybase-issues/issues/2230#issuec... That operation should be basically "curl ..|gpg-key --to-ssh", but instead it exploded into 10 line bash script, complete with parsing gpg output with grep/awk.

Just reorganizing existing commands into subcommands like 'gpg encrypt' instead of 'gpg --encrypt' :)

As for key management, keyrings and trust, I think a proper UI with decent explanations would help a lot too. This isn't rocket science, but it's too hard to guess what various abbreviations mean.