The article explains why it makes sense to rewrite history - it's so as not to push garbage out on the world. One of the big niceties of distributed, disconnected repositories is that you can muck about, try things out, make mistakes, correct them, clean things up, and then push that out to a public repo. The difference with git is that you don't have to make a separate patch, roll things back (possibly restarting with a clean repo from master), then apply the patch and make a "clean" commit - you simply rebase the commits in git.
When I'm maintaining code, I don't care about every little twiddle of bits that happened; I care about discrete, human-level, bug or feature related patches, and sometimes development in progress doesn't match up with that. Being able to rewrite history means being able to have not just maintainable code, but a coherent change history.
And it's perfectly possible to mess up and create ugly histories without rebase; that's exactly one of the prime use cases for rebase - cleaning up ugly histories. You want me to clone a clean repo from master and try applying pieces of my patch from scratch? Screw that noise! Even with the speed of git clone, I'd much rather pick, squash and rewrite commit messages in rebase.