At https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge, they say that the argument of whether to allow overwriting history in VCSes stems from two opposing views on what a project's history should be. One is that is shall be a raw, unedited record of events as they happened; the other is that is should be a (polished and adapted for future reading) story of how the project was made.
That's for how to add the commit on the master branch, once it’s there you can’t update it without breaking every fork and PR.
For all purposes, the history is immutable for example if you look at the v3.9.0b3 tag, it is signed so you know that this is the code that went into the release according to the person that signed the commit. If you changed any parent commit, it would change all childs and the signature would then be invalid which would be an issue.