I'm a little confused by what this is saying. It seems that you can create a basically identical commit with a different signature and thus a different (hashed) ID.

So basically you can take a Signature S1 and produce a valid Signature S2 over the same data that is not identical.

This doesn't seem like a very useful exploit primitive to me. Not nothing, but doesn't seem like a big deal. I feel like I am misunderstanding something.

This is the opposite of a hash collision (where two different inputs have the same hash), it's instead a case where the same input can produce two distinct hashes. I'm struggling to think of an actual malicious application of this.

You would need to have a malicious commit (eg. as part of a supply chain attack) which is signed by a maintainer (because their keys were stolen), and then when the project finally reverts the malicious commit, another attacker (without needing the signing keys) can recreate the malicious commit with a new commit-hash, which might trick automated tools into thinking it's a new commit, but the tree and metadata would be identical to the malicious commit, and it would be signed using the old (stolen) signing key that would since have been revoked.

Is that their point? Or is there some other attack that this enables? This just means that we can't blacklist git commits, since an attacker could produce a new commit hash that represents the same tree. But if an attacker already has the signing keys, then they can do this indefinitely even without this signature malleability. The signing keys would get revoked in both cases, and that's what needs to be checked.