I think the author balloons gpg signing into a problem and overlooks the impersonation aspect the signatures try to mitigate. Out of the cons listed:

Unknown, possibly unlimited future liability for the consequences of running code in a commit you signed

I don’t see how proof of commit authorship would change the warranties a piece of software is supposed to deliver. Sure it’ll make the untruthful claim of non-authorship harder (i.e. “I didn’t write this” when they in fact did); on the flipside, the signature would also protect the author from an impersonation attempt of a malicious/deceiving piece of code. Either way, I wouldn’t worry much about it.

Further implicitly cementing GitHub as a centralized trust authority in the open source world

This doesn’t hold. Commit signature is a feature of git itself, even though the article chooses to focus on GitHub. And afaik github integration of signatures doesn’t break code hosting elsewhere, GH merely allows you to register your GPG signature with them so they’re able to validate the commits, but the author is still able to enroll the same GPG key to other hosts.

Introducing unknown reliability problems into infrastructure that relies on commit signatures

Not sure what they mean by this. If your infra is set up to require signature, they might have valid concerns about impersonation and/or operate in a regulated environment.

Temporary breach of your GitHub credentials now lead to potentially permanent consequences if someone can smuggle a new trusted key in there.

This is a temporary problem, not permanent. After the breach the genuine author can go to the settings and delete the compromised key. Commits signed with a deleted key fallback to an unverified status.

New kinds of ongoing process overhead as commit-signing keys become new permanent load-bearing infrastructure, like “what do I do with expired keys”, “how often should I rotate these”, and so on.

Same with SSH keys, security is often a trade-off with convenience.