You're ignoring various parts of the equation, though.

- Writing a test for a bug is part of understanding the bug, much like rubber ducking, it helps you make sure you know exactly what causes the bug.

- The better you are at writing tests, the less time it takes you to do so.

- Having tests for the code means the code is testable. In general (but not always), code being testable means it's better code (more readable, less complex, etc).

- Having tests for code means you have to worry less about breaking it when making changes. This allows work to proceed faster.

So it's not just "did adding this test prevent this one bug from re-occurring", it's "did adding tests improve our development overall". The later is far more likely to be true than the former.

Maybe for you and your org though. This isn’t universal. I’ve worked somewhere that would use the phrase “whack-a-mole bugs” because teams would start thrashing and break each others’ shit over and over. There’s a ton of stuff we could have done — communicate (even just a tiny bit), less silos, communicate!, write better code, write tests.

When your problems are much more fundamental, like teams just flat out don’t talk, writing the test is an easier investment.

I disagree: when fixing a bug I usually start with writing a failing test that reproduces and exposes the problem, and then fix the problem so that the test passes.

Understanding, reproducing and fixing the problem is the hard part, once that is done making a test out it hardly takes any time.

Writing the test does not only prevent regressions, it also helps with confirming you actually fixed the bug.