https://github.com/libexpat/libexpat/pull/789/commits is a PR of 16 related commits. Many of them make sense individually, but are depended on by subsequent commits.
Reviewing them separately makes sense. It's easier on the reviewer (and future readers) to handle multiple smaller changes, especially since each is more tightly coupled to a rationale in the commit message. Unfortunately, github's PR-focused UI doesn't really make this per-commit review as convenient as Gerrit does.
Additionally, the last two commits are authored by another contributor. This metadata would be lost in a squash.
Of course, each intermediate commit must build and pass tests. WIP and cleanup commits are squashed locally before final review/merge.
You could argue that all of these could be separate PRs, but I think there's value in grouping them up with that final merge commit, showing what one was trying to do at a larger scale.
Squash merge.. zero downsides.. hard to take you seriously.
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.
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.