Neither is claiming that rebase breaks bisect; I can tell you what does break bisect: commits that are noise. Commits that weren't properly cleaned up. Commits that revert changes made in the previous commit. Commits that are conceptually related but not squashed together, or worse, separated by unrelated commits, etc, etc. You know what these have in common? They can be fixed with rebase.
Sure, rebase can be abused, but committing in general can also be abused. Rebase offers the opportunity to make history legible, instead of just some ASCII journaling of a codebase.
And you're also wrong about rebasing onto the tip of a branch, as others pointed out: in my experience, it very rarely introduces build errors, and on the rare occasion it does, it's easy enough to fix them, commit, rebase to squash into a fixed commit, and push. As someone who rebases on a regular basis, and has done more than a few bisects to the same codebase, I can tell tell you rebase works just fine with bisect.
Sure, rebase can be abused, but committing in general can also be abused. Rebase offers the opportunity to make history legible, instead of just some ASCII journaling of a codebase.
And you're also wrong about rebasing onto the tip of a branch, as others pointed out: in my experience, it very rarely introduces build errors, and on the rare occasion it does, it's easy enough to fix them, commit, rebase to squash into a fixed commit, and push. As someone who rebases on a regular basis, and has done more than a few bisects to the same codebase, I can tell tell you rebase works just fine with bisect.
EDIT: I'm not the only one who thinks this way: http://darwinweb.net/articles/the-case-for-git-rebase