That's definitely the real reason behind this situation: The people behind large projects tend to have to manage tons of releases, branches, and commits along with the code itself. The solution that many projects use is to appoint a few people with The Power to Approve Commits, so that all this meta-information can be managed more effectively. Every commit that you create is a set of extra objects that need to be downloaded, examined, and discussed separately. If you have people to manage this, then the amount of meta-noise goes down. Otherwise, you have some people trying to merge branches with tons of tiny commits with names like "Argh why doesn't this work" instead of squashing them together, increasing the amount of noise that you must look through.
So it is understandable that anyone in such a position would reject a change which amounts to editing a word to a synonym, in terms of the meaning of the documentation. What really matters with documentation is the question "Does this commit improve the ability of the documentation to teach users how the product works?" Rarely do I see a pull request and think "Is this commit offensive or discriminatory?" because people submitting code that is offensive is a pretty rare occurrence, rare enough that it almost seems impossible. But here's the issue: In this case, there were at least two Commit Approvers involved. When the commit was rejected, the committer obtained permission from another Commit Approver. When the commit was pushed through, then to the first Commit Approver, the committer appeared to be breaking the golden rule: Only the appointed Commit Approver may approve commits. Which is why there was a chiding comment left by that first Commit Approver. Now of course, looking at one side of the evidence, it is very easy for some people to jump to the conclusion that misogyny is involved.
It just so happened that the commit in question contained so-called Colored Bits [1] - it carried gender equality connotations that some people found to be objectionable. What people don't seem to realize is that maybe not that much attention was paid to what kind of meta-meta-information was associated with this commit (itself being a piece of meta-information about the documentation, a piece of information.) Maybe the person in charge of approving commits had a lot of work on his plate that day and only wanted to focus on what a lot of developers say is the Part That Matters - the code. So he acted bureaucratically on this pull request. It is possible to act in an entirely robotic manner and still get accused of things like gender bias. Looking at the backstory of this commit, it doesn't seem like there was any malicious intent by any party at all.
What could have been done to mitigate this situation? Maybe if there was a single person in charge of managing updates to the documentation, who curated the incoming commits in large batches before creating pull requests to the Commit Approver, then there would be less friction in getting documentation updated. Maybe if the executive people at Joyent were more understanding of the situation, then they would not have fired one of their employees over trivial circumstances.
[1]: http://ansuz.sooke.bc.ca/entry/23
