If you are working on a web app that you can bisect and retest each new version in a few seconds it's an amazing tool.
If you are working on a stack of huge server apps with 1h+ build times, and complicated start up procedures you aren't going to find besect very useful at all.
But even if your build times are that ridiculous, git bisect is still useful because it is not just a constant time improvement - having to do log(n) builds isntead of n is going to be helpful no matter how long each build takes.
There are tons of folks out there for whom git usage is a necessary but background element of some other task they’re doing, and so they know to do one or two add/commit/push style flows. I’ve had many people say to me “every so often I get git errors that I don’t understand so I just delete the whole directory and clone again”
If the commits weren't squashed, we could have narrowed down to the individual commit that introduced the (revenue affecting) bug and probably fixed the issue relatively quickly. IIRC, any git-bisect shouldn't take more than ~12ish attempts to find the breaking commit, no matter how many commits there are. At least we knew which PR the issue was affected by, but instead of just hot-fixing what was probably a one-liner, we had to either revert the entire new feature or read through all the changes to find the issue.