If I deploy a bug despite "unit" tests, then it will probably be caught by 2nd tier tests 1 day later, which will already be more expensive since I'll need to read report, context switch from other thing, fix it, redeploy, wait for CI, wait for 2nd tier tests, etc.
If it will not be caught by 2nd tier, then it probably will be caught by validation engineers, which not only costs their time, but they also have to contact me / fill some bug, I need to get familiar with it, context switch again, fix it, redeploy, wait for tests #1 and #2 and wait for their confirmation
If it will be released to actual customers then there's reputational dmg (can be huge depending on impact), possibly some lost sales / customers, probably a few weeks before it goes back to me thru customer->???->validation->me
So, while 100x more expensive is some extreme case, then usually the cost is very significantly higher the later you find the bug.
But what about HW bugs?
I think those can be really, really expensive.
Imagine catching hardware bug which affects some computation that MUST be fixed at hardware level.
Catching it before release and catching it after selling 100m copies is tens of bilions of dollars difference for top GPUs and CPUs.
Why do you think that those companies are willing to build same product twice so they test eachother? It significantly increases the cost, but reduces the risk.
Think about CrowdStrike's incident: catching that bug at dev level would cost them shitton times less than what actually happened :P
Their stock dropped by like 45%