Earlier quoted context omitted.
The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…
I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.
* In Subversion, people track patches using tools like quilt to manage them before actually putting them together into a commit.
* In Mercurial, people use `hg mq` which is like a more featureful version `git-stash`.
These are basically all ways to track a series of patches prior to 'committing' them into the code base shared with others.