Not a fan of rebase, particularly when habitually combined with squashing commits (the two seem to always go together).
The benefits of a "clean" history don't outweigh constructing a weird false history. With rebase the pull request I raise today might say I wrote the code, say, three days ago. It erases the history of updates being merged from master, even when those updates were significant to the final change set. Plus it encourages really poor commit messages (because they'll be squashed) and over use of force push (which silences useful errors).
It's also a pain during pull requests. If you rebase as you go, reviewers can't see deltas; if you rebase at the end you are letting authors merge unreviewed code (in other words, relying on people to literally never make a mistake), or you're making reviewers review everything twice.
All for what? Avoiding some merge commits that are incredibly easy to identify? The value is weak and the risk is high.
About the only time a rebase+squash is useful is if you have an excessive amount of commits in a branch, and you want to tidy it up before review. That makes sense. But otherwise, meh. Merge works fine and doesn't create low-value busywork.