I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.

You're right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.

There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can't establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.

Squashed commits are not atomic, unless the MR is so tiny that it logically fits into one commit. This is often not the case, though. It is frequently the case that the overall task requires modifying multiple different systems, which should themselves be their own commits, with tests for changes added to the same commit that makes the change.

A well-crafted MR should tell a story in its commits, with changes proceeding logically from one another.

It seems to me what you are really arguing against is poorly crafted history, which I fully agree is something to be stamped out.

To address the specific commands you mentioned:

1. That's... really besides the point of git bisect. It's binary search to find bad commits. If the selected midway point happens to be a formatting commit (which I'd argue should really be handled by pre-commit hooks anyway) and that commit is broken, it just means that the search proceeds to the midway point between that commit and the known good commit.
2. You can revert a range of commits, but the point of crafting a quality history is not doing things like having separate commits for tests. Tests belong with the code that it's testing.
3. First off, any reasonable usage of git will have ticket/issue numbers in the commits that you can use to look up the full task information. But also, git blame won't show the rename commit if it's a separate commit from any changes (which it absolutely should be, due to how git handles renames). And finally, if you care about getting more detail about why the code is the way it is, git blame isn't even the right tool for the job anyway, git log -L is.

You don't share feature branches. So you always know precisely what is shared history: the commit you branched from.

The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.

I rebase dozens of times a day and have never had a single issue with it.

If you're bothered by repetitive merge conflicts (which, in my experience, are quite rare if you're doing things correctly), that's what git rerere is for.

Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.

I constantly rebase my feature branches regardless of how many commits there are and whether I’ve pushed any of them. So long as no one else has checked out my branch it’s perfectly safe. Personally I find rebase merge conflicts far easier to work with. Traditional merge conflicts are “Here’s someone else’s changes, figure out how to merge them into your feature branch.” Rebase merge conflicts are “The main branch has changed since you made your changes. Re-apply your changes to the new base.” For me/my brain, the latter is so much easier. The only time I ever run into problems is when there are merges in the history I’m rebasing. Which I avoid by never merging into my feature branches, only rebasing.

And if it goes wrong, just git rebase —abort. Or if you already completed the rebase, git reset —hard origin/YOUR-BRANCH. Or if you majorly fucked up, use git reflog to find a good commit and reset to that. Zero risk if you know what you’re doing.

I often end up squashing all my changes into a single commit, rebase it, and then reset HEAD^ to rewrite some commit history.

Brute force, but better than resolving 10 conflicts in the same file over and over