I feel like if I committed locally more often and merged before pushing I would use it way more often.
Honestly? Almost never.
I guess more traditional methods of debugging code are good enough to identify where problematic issues are, and git blame is enough to identify the offending commit.
Historically I've used bisect on codebases I wasn't familiar with knew there was a regression I was trying to fix. If you can automate your regression testing with a script git bisect is really powerful and will save you _a lot of time_. Although if it's easy to test given the logarithmic nature of bisect maybe writing the script might not be worth the time.
I have used it exactly once 3 years ago to track down a regression and find the offending commits, while having no knowledge of the code base or architecture.
I don't use git, although fossil also includes a bisect command. However, I have never used it so far.