Conversely, people get too enamored of rebasing as a way to solve the problem of merging in lots of junky commits.
There are lots of ways to rewrite history and clean it up. Rebasing is just one of them, and it's one that can force you to spend more time resolving conflicts than you otherwise might have to (since you have to replay all of your commits and resolve any conflicts caused by each one individually).
There's no reason why rebasing is a better way to clean up your history than squash merging (or even -- carefully -- using git reset).
My point was that many git users don't understand git all that well, and I think that encouraging everyone to rebase is a bad idea.
If you're going to promote a particular workflow as the the one that "should be the weapon of choice," I think the workflow of merge-master-into-feature-branch, squash-merge-feature-branch-into-master is a more user friendly alternative, since then the cases where rebasing is expensive never even come up.
And yes, you're right that I was remiss not to mention the --soft part. The git reset workflow is one that I would definitely not encourage people to do if they don't understand git well.
There are lots of ways to rewrite history and clean it up. Rebasing is just one of them, and it's one that can force you to spend more time resolving conflicts than you otherwise might have to (since you have to replay all of your commits and resolve any conflicts caused by each one individually).
There's no reason why rebasing is a better way to clean up your history than squash merging (or even -- carefully -- using git reset).