Only… broken… for… collisions.
This is going to be my last reply to you, because this response is so confused that I think you're beyond help.
SHA-1 is used to validate long messages.
1. The sender, Alice, computes the (relatively short) SHA-1 hash H of a long message M
2. Alice cryptographically signs the hash H with a signature S
3. Bob can verify the whole message by verifying that the hash H is correctly signed, and then re-computing the SHA-1 of the entire message M, to verify that his computed hash matches Alice's hash H.
If Eve can compute a "SHA-1 collision," Eve can make a fake package X (like, say, malware instead of a real software package) that has the same hash H as the message M that Alice has signed. With that, Eve can trick Bob into accepting her malware by presenting Bob with her fake message X and Alice's real signature S. This works, because Alice really did sign hash H, and X and M have the same hash; their signatures have "collided" with catastrophic results.
To say that SHA-1 is "only broken for collisions" is to say that SHA-1 is broken for PGP.
Anyway, I'm done here. I hope we both agree that you deserve PGP.
Not even MD5 is vulnerable to a second preimage attack.
The actual problem with SHA-1 is that Eve can generate two different messages with the same hash, one innocuous and one malicious. If Eve can get Alice to sign the innocuous message then Eve can use the signature to attack Bob using the malicious message.
Collisions are still catastrophic for most applications that use signatures, but it’s a wee bit harder to pull off an attack using pregenerated collisions than if you can find a second preimage. (Collision-based attacks need a signing oracle whereas second preimages do not.)
SHA-1 is only broken for collisions. So far the best anyone has come up with for an attack on the SHA-1 in PGP is the mostly impractical Shambles attack on the PGP web of trust. This has been fixed in the implementations. When and if someone can demonstrate a practical attack using SHA-1 then more measures will be taken. This stuff is a little more complicated than just identifying particular hash methods in the list of features. This sort of thing is inherent in a long term encryption standard. You can't just randomly break things because you have a bad feeling about something.
>...but PGP's public identifiers are paired with secret keys.
In exactly the same way that, say, signal links its long term private identity key to public identifiers (your phone number). The problem is inherent in using public key cryptography for messaging. Most PGP implementations identify where that private key is kept and allow the user to protect it with a strong passphrase. That is opposed to how Signal depends on whatever security the device can provide to a key hidden somewhere on the device.