For context, even though our organization is fairly large, and we have stringent policies around what sorts of activities people are permitted to do with code bound for production, we purposefully aim for as much freedom and flexibility as possible "off master".
Reproducing a situation where this is unfavorable is not difficult. Simply cloning a repository and rebasing starting from some ancient hash, then publishing that branch will email everyone who committed to that branch (if they haven't adjusted their email settings already) with an email for every commit they made, and it's extremely unlikely that they care about this or would find the email welcome. For a non-contrived example of how this happens in the wild, here's the latest response to "why were you doing that".
A test branch was created for iterative testing and development, specifically for deploying onto hardware in the field, with the end goal that the resulting branch would be used to create a diff. A separate, recent commit on master, which was required for further testing, required master to be rebased onto the feature branch and pushed to the origin to be pulled down and deployed to the hardware. Because of this, history was rewritten and a subsequent push would have notified all committers whose commits were included in the new history to be notified.
So tl;dr; people don't always care a whole lot about managing diffs when in the field.
It's not exactly a frequent occurrence, but I find myself having a hard time explaining "why not" when it does happen, other than "because phabricator is going to generate a lot of email that we don't want".