GA uses GPG for encryption but it's neither fast, user friendly or particularly secure (C software from the 90s with huge legacy debt...).
It'd be really nice if you could use a faster, simpler/leaner, modern and reasonably secure piece of software instead for encryption in GA.
I'm not too deep into this but https://github.com/FiloSottile/age looks like an ideal replacement for what GA currently needs GPG for:
It's fast (encrypts /dev/zero at 1.4GiB/s on my machine), modern, simple and designed to integrate well with other tools via the command line. Its creator is the Golang security lead, so the crypto is probably good too 
Age seems to be closing in on its "production-ready" 1.0.0 release, so it might be worth having a look at now.
Mostly people pick on gpg's public key crypto implementation, and mostly I think, because public key crypto is easy to pick at. I have not seen many such arguments about gpg that seem very convincing to me. I see that AGE also implements public key crypto.
The way git-annex uses gpg for encryption=shared does not involve public key crypto at all, but uses AES-128, which is about as close as there is to a standard for encrypting things. (If you prefer AES-256, gpg can be configured to use that instead.)
git-annex already links to an AES implementation for other purposes and could probably bypass gpg and use that, but that smells of implementing your own crypto. (AES ECB penguin comes to mind.) AGE does not seem to expose any non-public key encryption, so it could not be used for encryption=shared, I think. (Unless perhaps the public/private key pair were stored in the repo as the shared cipher?)
While encryption=hybrid uses public key crypto, it's only for encrypting a cipher file, which then gets used as an AES key. So if encryption=shared can't be done with AGE, encryption=hybrid can't either.
That leaves encryption=pubkey and encryption=sharedpubkey, which I suppose could have variants implemented using AGE.
I don't like the idea of git-annex supporting more than 2 encryption programs, and even 2 seems like 1 too many. Every one will be an ongoing cost. It's not clear to me that there's enough of a benefit to support AGE, or that it would be the best choice for a +1.
Ah, this is not about the underlying algorithms and theories. Those are more than sufficient in our pre-quantum world and, as you said, AGE isn't fundamentally different here.
What I'm mostly concerned about is the quality of the implementation; especially the non-functional aspects like speed, UI and simplicity (some of which also have security implications).
The actual encryption is done symmetrically but the encryption of the symmetric key is done asymmetrically if I'm not mistaken.
This is not what age aims to replace though, it functions the exact same from a high level AFAIK; just with a different implementation that satisfies different goals from GPG.
That definitely smells of homebrewed crypto. This is why I would love to see something like age used: It's a pre-made, (supposedly) secure, standardised crypto system/library that you can feed files into and it simply gives you encrypted files back. No faffing about with complex key setups or other brilliant UX anno 1999.
I'm not sure I follow, couldn't you just generate an age keypair and simply store that in the repo?
Does the current gpg-based implementation not do it just like that?
Me neither and I understand your point but the problem with that approach is that it leaves absolutely no way to migrate away from GPG.
GPG is a complex beast that will likely need replacement within the next decade and age seems like the most obvious alternative for use-cases like git-annex.
Only time can tell whether it actually becomes the new file encryption standard but it seems like the most likely candidate right now.
Sequoia-PGP could be another contender (OpenPGP in rust). There is a sq command line interface that is equivilant to gpg.
It should be able to decrypt objects in repositories encrypted using gpg. If that works well, git-annex could support it in parallel with gpg for some time, then deprecate the gpg support and eventually remove it. This is a more appealing path than supporting multiple encryption tools indefinitely.
This issue is a pre-requisite for using sq, although presumably the low-level library could be used directly to avoid the issue. https://gitlab.com/sequoia-pgp/sequoia/-/issues/766
No, it uses gpg --symmetric which is much simpler and also likely more secure.
As far as gpg's UI complexity, it's a problem to some extent (although every one of those options presumably has a user), but notice that a git-annex user who uses encryption=shared never has to touch gpg's interface at all. This is by design. It's only with encryption=hybrid and pubkey that the user is exposed to the complexities of public key crypto, and I expect that mostly users who already are familiar with that and need the inherent complexity of it will use those.
I don't follow this reasoning; the openpgp standard is a well-established standard with many implementations, and so it seems likely that an implementation of that standard will be what replaces gpg, if anything.
(It also is possible that gpg eventually ends up being reimplemented using something like Sequoia-PGP under the hood to gain the protections from C-level security holes, which are certainly a real concern.)
The biggest reason to use age over PGP seems to be in the simplicity / attack surface. It deliberately does not include options to combat complexity and insecure configurations. It also has a lot less baggage and complexity than PGP: obscure packet-based format, web of trust, subkeys - age does a single thing, and it does it well. I do have a use case for hybrid encryption, but I'd rather not touch GPG ever again if I don't need to. Just the squabble about importing keys without identities makes me want to stay far far away. Age keys handle like SSH keys, so if you have a strategy for those age fits into your workflow very easily.
Age also supports passphrase derived keys now, so the "shared" use case is covered.
https://crates.io/crates/sequoia-chameleon-gnupg should be possible to use as a drop-in replacement for gpg. Assuming they implemented enough of gpg's interface.
To try using it with git-annex, it should be sufficient to run:
git-annex now supports using any program that implements the Stateless OpenPGP standard for remotes using encryption=shared
Eg, to use Sequoia's sqpop:
That fully interoperates with gpg, though it's probably a good idea to specify an enryption profile that is backwards compatible if interop is a concern. Eg:
For other encryption= schemes, Stateless OpenPGP is not yet supported, mostly because it's not clear how to manage the encryption keys. See this todo support using Stateless OpenPGP instead of gpg