It's more like criticizing a file system for lacking journaling, and then having its users respond that it does so because it gives you extra power to do things that a journaling file system would stop you from doing--or to implement your own if you see fit.
It's like the guy sells a commercial non-journaling filesystem, and he is trying to argue that journaling is a horrible idea... while everyone switches to his competitor's journaling filesystems.
It's sad when your product is no longer relevant, but that's no reason to make up reasons to attack its competitors. That just makes you (and your product) look stupid.
What I've seen in corporate America, makes me think his product is far too permissive for a lot of places, places which won't dare touch Git.
These people are silly, though. I don't know of a single version control system that doesn't let you change history in a straightforward manner.
At least in Git, the cryptographic commit IDs will change or be invalid when a commit is changed out from under you. Most other VCSes are blissfully unaware of history rewriting, and thus someone nefarious with access to the central repository can easily forge history.
I bet that never makes it into the marketing literature, though.
Are the revisions cryptographically validated, and are there other copies of the repository to compare against? If not, it doesn't matter, you can just edit the disk blocks.
(Yes, maybe you don't care about history that much. But if history is a tool for developers rather than the legal team, you shouldn't care if the developers mutate it.)
Git is aimed at people who know what they are dong.
Others will benefit from a more restricted feature set.
The bottom line for me is, that criticizing Git for not being immutable is like criticizing Ferrari for being too damn fast.