I don't like the idea of history rewrites; that word tells you more about the implementation than the conceptual changes you're making.
I like to think about history changes like this: I check out a commit, make some changes, then I redo all the changes I had done previously. Now I reset the old branch to this new head.
This also reflects one implementation detail: your old hostory isn't lost, there's just no more references to it, so you don't see it. The commits are still there, until they get garbage-collected at some point. In other words, the git "history" is immutable and cannot be changed; you can only create a modified copy.
I argue that it is representative of those ideas. Consider how history is written and what happens when it is rewritten. First there is the event, then what was written about the event. To rewrite history, the old writing isn't gone, but may no longer be referenced. ReRead that thinking about coding.
I'm also not advocating rewrites, so much as advocating to use it as a means to an end, communicating.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.