But in one case, damage is mitigated because the sys admins didn't assume everyone is infallible and strictly adheres to protocol.

The correct way to deal with fallibility in this situation is to make it feasible to change secrets when they leak, not pretend they weren't leaked.

That doesn't prevent someone from not following protocol.

It's not their job to prevent that.

It is a sys admin's job to mitigate damage from security leaks and to introduce hardened, fault-tolerant security paradigms.

You are just hacking the leaves. Once the secret is posted. It is public, it has multiple copy elsewhere on the internet. Even if you delete there is a copy kept somewhere on the internet -- and that's not an assumption. For example, iirc, Github copy is dumped to google every some-x-time.

Hmmm, it seems like having layered security, where accidentally exposed credentials aren't automatically "game over" would be better than not.

Not sure how practical that is to implement for every technology, but for many it could probably be done.

Seems like a time+money vs risk trade off thing.

Is it mitigated? Once it's leaked you can't force everyone who may have captured it to delete it. So GitHub deleting it doesn't solve the problem.

The definition of mitigation is to make something less severe. Yes, GitHub making this policy as clear as possible and allowing controls to toggle it per-repository or per-account mitigates the problem.