Where git differs is not in its mutablity, but in how it allows you to move around the head of a branch in a more free fashion than most other DVCSs. (I don't mean "more free" as a value judgment here, just an observation that it is a superset of typical capabilities.)
It should be pointed out this only address about a half of the objections you can raise for this re-writing; it is not true that you lose things because of the re-writing, because you can get them back from the reflog. But it is of course still true that history rewriting in the sense that most people mean it is true.
Basically, from a technical point of view this is a non-issue, but from a human point of view it still can be.
Personally, I'm willing to concede this is a powertool and perhaps isn't for everyone, and by the definition given it's not a "best practice", but I don't think I'm willing to accept that definition in general. I'd prefer something more relative to the local user set, not go for a global definition. Perhaps some teams would do nothing but shoot themselves, but in my experience with my team and the local related teams, history re-writing is a net gain in terms of how it impacts how we work. And it's hard to convince me of a point my personal experience doesn't correspond to.