You can change public branches. You usually shouldn't because this makes life difficult for other people if they are also using that branch. They would have to rebase their work on top of your revised history. Many Git users would have no idea what to do if
git pull stops because of a merge conflict.
master that are used as a starting point for other branches are holy, and rewriting their history is a big no-no. But feature branches are not meant to be used by other people. They are meant to be worked on, merged, and deleted.
So whether rewriting the history of a branch is acceptable depends on the social contract around that branch.
Within an organization, nothing beats talking with coworkers if you try to collaborate on a branch.
For a pull request based workflow, the expectation might actually be that you rewrite the branch history during the review process so that the history is always nice and compact, without many fixup commits.
This touches on the question what a Git log should represent: is it just a record of what changed when? Or is it a story that explains what was changed for which reason? No one creates a masterpiece on on first try: good stories need editing. When I review pull requests, I vastly prefer PRs that have an organized, readable history instead of PRs that show all the dead ends and problems that were encountered during development.
A force-push is not necessarily an anti-pattern. The need for a force push is merely a warning sign that you are trying to perform a destructive operation. In most cases
git push --force-with-lease should be preferred as it ensures that you do not destroy commits that you did no know about.