Rebasing leads to either having long stretches of non-compiling commits in history or giant non-bisectable commits. E.g. you added a method call on your feature branch, that method was renamed in master while you were working on your feature. If you merge then your commits still compile and I can use automated `git bisect` the way it's intended. If you rebase then your commits don't compile and I can't bisect through commits on your feature branch. If you squash then your whole feature development becomes a single monster commit and I can't bisect through it.
I agree with having as many commits as possible be compilable, but that's not the sole criterion, because there's a tension between that and having granular history: if you squash the whole history of the repo into a single commit then that means 100% of commits are compilable, but it's still a bad move. Conversely, a non-compiling commit in between two compiling commits is not a big problem (you just make sure your git bisect script skips non-compiling commits) - what really matters is keeping the diff between two successive compiling commits as small as possible. IME the best way to achieve that is never rewriting history.