As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.
Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).
As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.
Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).