Coming from a SVN background, one of the hardest things to get used to when working with DVCS systems is the way they all seem to regard any uncommitted change whatsoever like a ticking time bomb.
In Mercurial, if you try to fetch changes and you have any uncommitted changes in your working copy, you have to jump through hoops to get it to just merge the incoming changes in. Try to switch branches? It'll force you to shelve everything and then you have to immediately un-shelve it all on the other end. (SVN has no trouble with either of these scenarios.)
Git is about the same way. I'm working side-by-side with another developer on a project, and I just tried to cherry-pick one of his commits into my fork. It refused to let me because I have uncommitted changes in my working copy, on completely different files than the ones changed in his commit. There's not even a merge option; apparently I have to stash my changes first!
If a person were to treat something completely harmless with such extreme caution, I would call it a "phobia," an irrational fear that should be regarded as a mental disorder. But Git and Mercurial were designed by two different teams of intelligent, rational developers, so I have to wonder if they know something I'm not aware of.
Is there a technical reason that justifies this attitude towards uncommitted changes? And if so, why does the problem in question only seem to exist on DVCSes?