IIRC it's deliberately done this way for a number of information security reasons. If you look through the gnupg manual, there are references to things like "on old systems, this program must be setuid root so it may lock memory pages". Presumably it's desirable to require such a thing in an isolated process rather than the entire application utilizing gpg.

Since quality CLI implementations must be provided and exist anyways, why not provide the programmatic interface (libgpgme) as a thin veneer over it, as if the commands are being run from the shell?

I believe that it's primarily that GPG has been implemented in such a way that console concerns invade most of the program, but I've never actually looked to verify.

Probably the license and/or lack of an appropriate licensing exception.

Another posted indicate code issues, but I think you're right this is at least a big reason. GPG is GPL licensed, but GPGME is LGPL licensed. A library version of GPG would have to be GPL licensed as well, which would require any programs linking to it to also be GPL.

With that, for GPGME to be LPGL there can't be an actual coupling of code between the two or else GPGME would have to be GPL licensed itself. (Though you could argue the distinction here a bit murky)