most people tend put more than one atomic change into a single commit,
That's a people problem. Correct it through proper training and mentoring, not letting it continue just because "that's what people do."
Historically, some people were afraid of "wasting" commit numbers (CVS, SVN, mock revision numbers in hg), but git has no concept of an incremental commit number, so you can burn through as many commits as you want without feeling guilting about running up an auto-incrementing counter.
How do you "waste" commit numbers? They're just numbers. I believe the concern is about log space. (And git has a log too.)
Hopefully someone reads that log and they shouldn't be bothered by a thousand trivial changes, the reasoning goes.
Which is true to some extent, it's just that everyone doesn't get it right ... and that's where your comment about mentoring and training comes in. It must also be ok to make mistakes as to not try to hide slip-ups in the next commit.
I have worked with people who are obsessive about keeping auto increment numbers in databases "tidy". It's obviously nonsense but some people aren't logical. The same thing applies to some projects fears of actually following semantic versioning. Numbers are infinitesimally cheap, there should be no fear about burning them.
That's a people problem. Correct it through proper training and mentoring, not letting it continue just because "that's what people do."
Historically, some people were afraid of "wasting" commit numbers (CVS, SVN, mock revision numbers in hg), but git has no concept of an incremental commit number, so you can burn through as many commits as you want without feeling guilting about running up an auto-incrementing counter.