Squashing down a PR to a single commit erases all of that history and we have no idea when the change was made, who made it, who to talk to, or why it was made other than it was part of a larger feature set.
It might work fine for smaller PRs, but where I am we have multiple teams each working on a task that can take months to complete with lots of testing before it's ready to merge into a release branch.
I don't argue for squashing down the whole branch into one commit. That's silly and could be throwing away valuable information. But cleaning up the history using rebasing is still possible. We use "fixup!" commits so that a simple autosquash does the right thing most of the time.
I've actually had developers undo over-eager squashing before and introduced them to both the reflog and interactive rebasing. They are shocked the first time they learn to "undo" a rebase, but it's a liberating experience to actually understand git.
The reason you use blame is to find the exact commit that changed a specific line, and hope to find the rational / decisions that lead up to this change, assuming people are disciplined enough to document that in their commit messages. If not, maybe you could even ask Josh if they still remember why they changed things a certain way.
Many developers commit append-only until their feature works, which means there are a lot of noise commits in between, which they don't (know how to) clean up. Rather than having all this noise, projects opt to squash the commits instead.