I use interactive rebase to construct a useful commit history that will communicate intent to future developers. Things like "move a file first, refactor it in a separate commit" make a huge difference when someone's coming around to view the file history later, and a squash merge removes all that information that I've meticulously encoded in the commit history.

My preferred workflow on a team project is to have well-crafted commits with merge commits. The merge commits signify the wider intent and link back to the PR in GitHub, while the interactively rebased commits tell the story of the steps to get from point A to point B.

Loss of utility of tools like git bisect, conventional commits, etc.

Git blame is less useful when what were individual commits associated with lines are instead rolled up into a massive commit, such that each affected line is now described by a more general commit.

It can encourage lazy developers to submit shit commit history in PRs knowing it's going to be squashed anyway, making PR harder.

Losing granularity, obviously, no? Of course it depends on how big branches get before they’re squash-merged, but squashing can make things harder to bisect, harder to track independent semantic changes that overlap, harder to read comments & history, harder to cherry-pick small fixes… lots of things. You don’t notice the downsides until you have to manage release branches or spelunk through the history to find bugs or figure out who wrote some line of code from long back.