I decide whether to commit what I have done or whether to stash it for now, based on what state it is in.
If I am still in the exploratory stage of the work, I usually wont commit, I will just stash and come back to it later.
Its a useful thing to be able to do at time when i am not yet ready to COMMIT to the changes I have made.
I am not judging anyone or their workflows. It's the stash command that has the problem, because it circumvents git.
That said, my reaction to your comment is that you're taking "commit" too seriously. ;) Nothing in git is a commitment until you push. Nothing. If you haven't heard the phrase "commit early, commit often", consider that and take it to heart. If you have work you care about and even might want to save, then you should commit it. Git was literally made for the purpose of managing multiple versions of exploratory work -- to not use commits and branches for that purpose is to not use git to its full potential.
Stashing things you care about for some later time strikes me as the kind of use of stash that is the most prone to data loss. But again, if you're comfortable using fsck, none of this applies to you.
I prefer to commit discrete change sets (not features, or stories, just a discrete set of changes that achieve a piece of what I am wanting, dont break the code base and dont break the build).
I have heard that phrase, I live by it and encourage others to do the same. it is especially important when working as a part of a bigger team on the same area of the code.
Teams that commit early and often are happy teams :)
OTOH I use stash constantly, multiple times every day, when switching between branches, because sometimes its just handy to be able to put stuff aside to look at something else.
I dont recall ever losing code because of it, but it is certainly possible and its not hard to see how it could happen.