Trigger versus sustaining effect

Why does fixing the trigger of an outage not reduce your exposure at all?

These are two different mechanisms. They have no relationship in size or duration, and mixing them up is the standard failure of incident analysis.

The trigger only has to push the effective load above C for a moment: long enough to fill a queue, drain a cache or push latency past a timeout. Examples: a 2-second GC pause, a deploy, a brief dependency problem, a network partition healing.
The sustaining effect is the system's own amplification once it is in the degraded state: retries generated by its own slowness, cache misses caused by its own churn, timeouts caused by its own queue. Once the system crosses over, the trigger is irrelevant. You can remove it completely and nothing improves.

Three consequences follow. The third is the useful one.

Trigger size carries no information about outage size. A 2-second blip can produce a 6-hour outage. A post-mortem that names the trigger as "the cause" has explained the timing and nothing else.
The trigger is often impossible to recover from evidence. It happened before the alert fired, may not be in the logs, and may have been a transient in someone else's system. Teams spend the post-mortem searching for it exactly because it is the part that hides.
Fixing the trigger does not reduce your exposure at all. There are unboundedly many triggers and exactly one sustaining effect. If you eliminate the deploy that caused it, you have removed one member of an infinite set. The vulnerability band C/k < λ < C is untouched, and something else will find it. The only remediation that changes the probability of recurrence is one that reduces k or bounds the loop.

This is the strongest practical claim here, and it contradicts how most organizations run incident review.