Every times I hear these sort of justification my little rage meter goes up a notch. These arguments are all based on unverified and unncessary optimizations.
* How many times have you read a project history commit by commit? How much time the occasional typo-commit took you to read? The probalbe answer, if measure would be negligible. Yet you're ready to spend time rewiting history. Which can cause real and known time wate as people have to rebase remerge, and sometimes cause all the problem that have been outlined.
* The whole point of bisect is using a logarithmic search into history. The rare typo-fix commit won't affect its runtime. Again, this is wasting time for no measurable effect.
* Stop the micro-fixing commit already in the first place!
But what really annoys me is that all these are the symptoms of a deeper disease: mis-managed repos. This first thing to do if you have the legendary 50GB log show up in your repo is not to rewrite history. The first thing to do is to make an urgent note to review your repo management processes. How did that file get in there in the first place? Are you pulling directly in your main repo!? The correct practice is to always pull into a staging repo and only merge into main if clean. How do you know it's clean? Easy: use the double-staging repo trick: pull into a staging repo make sure everything is shape (human manual process) then pull into another clean-from-main staging repo and diff the history. If the diff is not empty, you know something is wrong. Only when diff are clean do you pull from that staging repo into main.
(BTW, that double staging is only necessary if you allow yourself to do cleanup in the staging repos. If you always insist on clean pull, then all the cleaning up is done elsewhere. This is not always possible / easy /efficient to do on busy repo. And on your private working repo, do as you please, as long as the pull then comes off clean.)
(Also, I recommend doing the same on your private working repo. I always find it easier to have clean copy of the main repo, one staging repo where my own cersion of clean-up history is kept and the real dirty-work repo yet a third repo. The fact that I prefer to work with mercurial which works best by cloning rather than branching pretty much enforce this discipline. It promotes happy collaborations since you never pull into your work repo and you never push from it.)