It's not unreasonable to force push a branch. Anytime you've rebased but already pushed you would need to do so. I've worked on an open source project where every commit was required to pass all the tests, so if you submitted a PR that had any commit fail CI, you would have to alter history and force push.
I also just like pushing to a branch on Github, even if I might rebase later. Circle CI is triggered through Github, so it's nice to have that triggered for me. Our staging servers (production data, your branch's code) are deployed from Github branches as well. Plus looking at diffs on Github is really helpful for me to spot errors—I'm not sure if it's the context switch away from my text editor, Github's diff UI, or what, but it works for me.
> Anytime you've rebased but already pushed you would need to do so.
And that's also unreasonable. Pushed history should be treated as immutable. If you broke the build, push a revert commit, fix the issue, and resubmit. And then fix your tooling to recognize rollbacks.
I tend to treat the history of the master branch as immutable. Working with a remote branch that needs to stay up-to-date with master has, in my experience, required rebasing and force-pushing the branch.
In this case, the person probably thought he or she was pushing "feature-wip" or something similar after cleaning up that branch's history. Not necessarily unreasonable. If master is out of date then
git push -f
throws away any remote commits (under old behavior).
If you are behind git warns you and says you need to pull first. By stating -f you are saying nope, throw that crap away and just take my version.
That's pretty extreme and warrants care. I have a hard time feeling sorry for people who are burned by this.