IMO, the way GPG was done killed what could have been a decent ecosystem. It's a combination of two factors:
1. Don't roll your own crypto.
2. The available code (gpg) is a colossal pain to use.
So for instance, how does something like KMail deal with gpg? There's no libgpg originally. There's just the gpg tool, so you've got to call it as a sub-process, and it really sucks:
1. You have to deal with process management, multiple filehandles, text parsing, non-trivial interactions, etc.
2. It's slow. You pay startup costs every single time. This is a huge problem on something interactive like a mail client, and it's dependent on things like the amount of keys in the gpg store.
3. gpg has very specific ideas about how it wants to be used, and not everything fits.
Say that you oh, want to do some stats on GPG keys. There's no libgpg to just read an .asc file and get the list of signatures from that, no. You have to call gpg, feed it the key, parse the result. For some things you might actually have to have gpg import the key first. Manage a fake home dir for GPG. Deal with the horrible performance as the keystore grows. A million keys at a gpg invocation per second is going to be around 2 weeks.
Unfortunately it's only now that gpg is effectively dead that the problem started to get fixed.
Also, at this point GPG is effectively a legacy technology anyway. Modern cryptographic thought considers GPG to be a terrible idea for a whole bunch of reasons that are deeply built into it, so the only solution for that is throwing it out.