For me the benefit is that I can revert or cherry-pick things one entire PR at a time, and I don't have to care if the author implemented their PR with a bunch of small "work in progress" commits.

And GitHub at least sets the author of the squashed commit as the one who opened the PR, not the one who merged it.

I can definitely see where it wouldn't work well for other workflows but I've had it work well on several teams and it seems easier than trying to get everyone to clean up their commits into nice, clean, well-titled histories before putting up a PR.

You don't have to rewrite the source branch to squash merge?

I wouldn't describe it as "cleaning up the history". And the goal isn't to save space, it's to keep a linear history where things ought to be working at each commit (to enable tools like git bisect and similar).

I personally don't ensure everything is working every time I commit - That's what CI is for. The exact process I work through while writing a PR shouldn't impact other people's workflows, so when I merge back into a central branch it should really only reveal the granularity at which I assert 'this code is working and good', which is NOT every intermediate commit I make. Squash merge is a way to do that that fits nicely with existing engineering workflows, like code review.