I think atomic commits can either bump or decrease your commit frequency.
If you had a giant piece of logic that wouldn't be atomic in multiple commits, but you have multiple commits on your machine for the sake of saving your butt in case you roll down a weird rabbit hole, then you'd probably squash before merging into master and end up decreasing your total quantity of commits.
If you had a lot of small changes that all were safe seperately, you might break up what could have been a single commit into several commits so that you have a more descriptive history, and increasing your quantity of commits.
I believe that atomic commits makes things easier later, if you need to roll back, stash, or branch out. It's just hard to keep the habit going and not become lazy :)
Since January I've been insisting that we make atomic commits, but now I'm looking to switching to squashing them into one before merging. This makes it a lot easier to roll back a whole feature and not half way through it.
Plus, our graphs look ridiculous, I'm easily 5-10 times over the others, but it's not that I'm doing more work, I just commit more often.
We're using atomic commits since 2009 when we moved to git. However: we very often merge features with --no-ff to make it way easier to back them out at once if needed.
That way you get the best of both worlds (very easy archeology and very easy backing out of features)
