As with most things, there's no silver bullet that applies to every single case; different workflows work best for different teams and projects. Gitflow is both reasonable and fairly simple to understand and implement, but so is commiting straight to master and tagging "when it's done" for a single-person hobby project.
There's also no free lunch, and maintaining a clean history (whatever that means) takes more effort than just applying a set of rules (such as, always rebase, squash commits) after the fact. Linus Torvalds has said it better than I could ever do[0].
As far as the article itself goes, the author maintains that:
> A few common commits on my branches are: “WIP,” “Run Rubocop,” and “Fix typo.”
And then goes on to say that the solution to this is to rebase, rather than creating better commits from the get-go, or just deferring any commits until the end of the feature work, and then staging interactively in order to create multiple thematic subdivisions, or just commiting the entire workspace.
[0]: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/...