Severity has almost nothing to do with how often a bug runs. It has everything to do with how long its output survives.
A wrong number in a response is just a wrong screen. Reload and it's gone. That same wrong number on a durable write becomes a record, and everything downstream reads records as truth.
Three things turn something trivial into an incident.
Persistence: the bug writes instead of returns. One bad commit per hour is 700 rows by the time anyone looks.
Fan-out: reporting, reconciliation, payouts and support all read that row. Correcting it means correcting four consumers that already acted on it.
Plausibility: the dangerous bugs don't throw. An off-by-one in a pro-rata split across multiple investors still sums to the right total. Attribution matched to the wrong obligation still balances. Nothing alerts, because nothing looks broken.
That asymmetry is what I keep coming back to. Patching the split is an afternoon. Reconstructing which deals paid what, in what order, across months of statements is the real work, and part of it is simply unrecoverable once money has left the system, or once deal state is committed on-chain where there is no UPDATE.
So I don't grade a change by how complex it is. I grade it by whether it touches a write path, how many systems treat that write as authoritative, and whether a wrong value would still look reasonable.
When you review a diff, what I want to know is whether reads and writes get the same level of scrutiny, or whether you hold writes to a different standard...