I think about who the audience for the commit messages is. In some places, the audience for them is the person tasked with writing the release notes. In that case, all your atomic commits are just noise and make their job more difficult, so in those places the commits will get squashed, and the main commit will be the feature with JIRA or other ticket number the squashed commits were about. And in that case your atomic commit history is gone anyway.

You can see how much time you are using for any of your commits by turning on Webstorm's time tracking and using that to create your change lists. I find this a great way to ensure consistency across a team and be able to answer questions about how much time I spent where, but people who love atomic commits find it constraining.

You may also want to reword your last paragraph, because it implies people not using atomic commits don't know about it and so would of course start as soon as they receive your wisdom.