It's an absolutely fantastic (though dangerous) command. It's also a good illustration of how git doesn't commit anything you don't want to see committed (eg, "git commit" doesn't do anything if you haven't done "git add" before, letting you prepare your commits more carefully than with other VCSs).
You need to test the version of the code you are going to publish, and unless you are publishing every time you commit, you don't need to test each commit.
I use git add -p whenever I've made too many changes between commits. I like for my commits to be of a single topic if possible.
If I use git add -p to break up a commit into 10 separate chunks, and find out something is broken, it's not hard to find the commit that caused the issue (if the commits are topical and not mixed).
Yes, but I think that's missing the point. It's routine to have lots of modifications to a code base at once -- the big one being extra logging or debug code floating around after a fix. At that point, you have to do a separation task where you prune out all the needless stuff.
That's what this is for. And it works pretty well. Any other helper for this task would look pretty much the same -- the goal after all is to translate your local hacks into a clean commit.
