It wouldn't mine, if I used git (I avoid git specifically for this reason, actually, and use Mercurial). If you're actually looking at your commit logs, I find that rolling back is trivial; I can't remember the last time I accidentally rolled back into an incremental commit.
Personally it feels more like an apology for git's bad behavior than a good method of development.
"I can't remember the last time I accidentally rolled back into an incremental commit."
I can't remember the last time I had a heart attack and died, but that doesn't mean it isn't going to happen in the future to me or to someone else. It sounds like it's just good practice for a public repository too, since your not the only one with access to it.
Short of explicitly installing a rebase extension, it simply does not allow you to do this sort of mucking about with the commit history. For "oops, typo" commits, you can very quickly (and I mean, "it's a button in Tortoise" quickly) roll back your change and keep it in abeyance until you've fixed the typo.
So basically you reject a powerful tool out of idealism ("must never ever edit history") and fix your commits manually, also forgoing the possibility of fixing earlier unpublished commits.
Instead you could code and commit (you know, use the VCS :P) without worry in a private branch, checking for problems afterwards and fixing them using rebase prior to merging the commits into the main branch. (where "must never ever edit history" actually applies)
Sorry if I sound snarky, but that's what this seems like to me.
Personally it feels more like an apology for git's bad behavior than a good method of development.