This seems to me a fundamentally bad idea: signing commits should be a "long lived" thing, but using an infrastructure designed for easily replaceable authentication (ie: add your pub keys to servers and remove/replace/destroy them at the very minimal suspicion of the private keys being compromised). And all the non-existing certification infrastructure (the article proposes one; we can end up with multiple incompatible signing/certification systems, none of them with the reach of existing OpenPGP). And at last, but not least, putting too many eggs in the same basket.
Commit signing with S/MIME also works great. The downside is that you have to buy an "email" S/MIME cert from one of the usual cert gatekeepers for a couple dollars, but in return anyone can verify the signatures without exchanging public keys with me (or building a web of trust), and expiration and revocation are solved problems (including verifying signatures made with keys that are now expired, which seems not really supported with SSH keys)
How is expiration a solved problem? You won't be able to verify commits after the cert expired without additional information because you don't know that the commit timestamp is valid. For code signing you there are timestamping services to solve this but this means that you are now dependent on a central authority which could just host verified hashes without all the crypto mess.
The only reason the article gives for using this over using the signing with GPG keys is that you will have an SSH key already. If you need to create a new key, are there any reasons for going for an SSH key over a GPG key?
I looked up the screenshots. The app looks like the most trivial possible UI for basic public key cryptography. Just a basic list of your/other people's keys (pretty much a contact list) and some ways to acquire them.
SSH keys if used in place of GPG would have almost the same UI. It's not the problem of GPG, but of the underlying concepts.
You don't need to be deep into cryptography, just understand some basic concepts from the wikipedia article, or whatnot.
The real reason is: I don't gain any security from signing my own commits, I gain security when other people sign their commits which they are currently not doing.
Therefore, making things easier to set up makes a greater contribution to security than strict, gold-standard security features that nobody adopts.
Signing with a separate hardware-stored SSH key on a dongle (e.g.: Yubikey/FIDO2) will allow you to have a long-lived key without the risk of compromise.
If you're using a dongle, I expect you'd have your other SSH keys there as well. Is there a security benefit to using a separate SSH key if they all live on the same dongle? I'm having trouble thinking through that. Although, certainly the hardware dongle has security benefits over SSH keys on disk.
