Squash & merge is objectively worse than rebase && merge --no-ff.¹ (Roughly what the article calls "no fast-forward".) "No fast-forward" meets all of the criteria the article's author proposes:
> 1. Combines all the code changes related to a single logical change
Yes: the merge commit is that.
> 2. Provides an explanatory commit message that helps people understand the intent of the change
This is no more or less true that squash & merge. (Although, I don't off the top of my head remember how good the automatic message in Github is.) But that's more a problem of an automatic message than it is the merge strategy, & squash and merge also has this. (I've seen numerous squash commits with "Fix CI, Fix CI, Code formatting, Fix Lint warning" in them…
Good commit messages boils down to the discipline of the coder. (And a reviewer being able to say, "Can you write a better commit message?".)
> 3. If you pick this commit independently from the history, it makes sense on its own
The merge commit.
What you lose with squash & merge is the history. The author does sort of address this:
> In case you are wondering if we are losing the individual changes, the answer is no. Each squash merge references back to a PR where the whole changes are tracked:
And while this is technically true, it's a reference only in the textual message (which Github will nicely turn into a link, but you must be in Github for that). "No fast-forward" will maintain those references in the git commit parent information, which means that tooling like git bisect should be able to see into it. But with a squashed commit, the closest you get is "some commit in this PR", essentially. Same with reverts: if just one commit on a feature branch is bad, you can simply revert that one commit. (Or, if most of the branch is bad, you can revert the merge commit & cherry-pick the good bits.)
If you don't want to see all the feature branch commits in the history, you can just follow first parents.
¹I prefer a quick rebase prior to merge but after code-review, as it is a good balance between the resulting history being readable, and not rewriting history while your reviewer is looking at it. But the argument here should hold regardless; the definition the article uses is sufficient, too.