> Nowhere does the author say that commit messages are meaningless
He doesn't. I say it. His commit messages are meaningless. To understand what's going on, you need to read his diffs, not commit messages. In his workflow, only reverts and merges provide any context, and for them git creates meaningful commit messages automatically.
What is different?
My point is, if you don't write meaningful commit messages for some commits, you probably don't need any commit messages for those commits at all. It reduces noise for people who read your `git log`. If you make a commit and then immediately revert it, instead of "foo", it's better to write at least "tried ...; didn't work".
The best solution, which the posted article suggests, is for git to natively support commit clusters. So that you can have just feature information and also meta information that isn't 99% invisible.