Because with a test suite, git bisect, and a history that's been reasonably well cared for, I can just tell git "find me the bug" and go do something else until it's done.
I don't like having to go fiddle manually for that to work.
Ideally you have CI set up so the average test failure email points you to the small patch that broke it.
For bugs from the wild that doesn't work, obviously, but I still prefer less friction.
Sounds like you've moved the work forward, where it always has to be done. Rather than doing it in a lazy manner, where most instances can be avoided. Is that a good trade-off?
Like most tradeoffs, it depends on the particular circumstances, I think.
I don't have this set up in my current gig, because we have more pressing priorities.
It is incredibly useful when you do have it, though.
Generally it's more important for really large projects - IIRC Android is really strict about not merging branches containing any commits that break tests, for exactly this reason.
As that implies, you wind up rewriting branches in this approach, too, but for different reasons.
Is it always possible to restore branches from the PR? e.g. do some code review systems automatically delete committed branches after a certain time period?
The author has only used bisect for a head-scratcher once, but I've used it often, sometimes to pin down bugs in code I'd never even looked at before.
That's not feasible if the commits are huge.