That's not for you to dictate to someone about some project you have no idea about.
Git is not a religion or cult.
Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.
If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"
"Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect.
Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use.
It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails.
Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised.
It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes.
There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.
Git is not a religion or cult.
Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.