This sounds like a completely arbitrary rule to me. I just don't get why people try so hard to avoid merges, and instead go down the rebase route.

Rebasing isn't just a pain, it's rewriting history. It's potentially dangerous in a team environment. You can't distribute your rebased branch without a force push, and that risks two versions of the branch's commits getting into the repository, or losing someone's commits altogether. It's usually not worth the effort.

It also presumes a simplistic development environment. Typically, I see branches that fit into categories; let's name them master, develop, small-feature, big-feature, next-gen-architecture.

Small-feature branches can be rebased fairly easily. There's not many commits, they're most likely worked on by a single person so the history isn't distributed, and replaying the commits isn't too onerous.

Big-feature branches are a little more tedious. This is where rebasing starts to become a pain; the big feature may have touched code that has since changed from commits of a few small-feature branches.

Next-gen-architecture is where it all falls apart. Trying to do a major refactor while simultaneously keeping customers happy with smaller features is a fact of startup business, if not most businesses. Rebasing becomes a multi-hour exercise because there are hundreds, if not thousands of commits to replay. And everyone on the team has this branch, and there may be sub-branches of it that are destined to be merged into it. All the sub-branches need to be rebased too.