That's very odd advice, as the reverse actually should apply.
Since (in GitHub) merging with squash costs just one click more to the maintainer, and one can't separate squashed commits, having separate commits should be the default behavior.
I'd say that it's preferrable to squash a disorderly branch history, but then, it's about being orderly rather than squashing for its own sake.
There isn't a one-size-fits-all doctrine here. It's subjective based on the goals, size, contributor base, etc of an individual project and the leadership of the project.
Hmm, I'm not sure that's true. Imagine if this excellent commit got squashed, there'd be something really lost: https://dhwthompson.com/2019/my-favourite-git-commit
The thing we care about is a bisectable repository where each commit does one thing only and that thing is described in the commit message. Squashing makes this impossible unless the pull request could have been written as a single patch without violating the above rules. Hopefully this is what the OP means with his first point. PRs that mix fixes to existing code and new features in a single commit will most likely be rejected.
This isn't true either. I've worked on projects before where if you have a PR that makes changes all across the codebase in one commit, then you will get asked to split that commit up.
1. if submitters squash their commits into one by default, it's hard to split, if the maintainer wants;
2. if they send separate commits by default, it takes only one extra click to the maintainer to squash them, if they want.
So, the second case is more flexible.