It sounds like rebasing this way ensures branches will not overlap at merge time. This presumably pushes the "combination of changes" into the rebased-before-merging branch, which (if nothing else) makes sure that one committer owns the bug, not two.

In case of merge that would be merge commit author.

Because it's really difficult to disentangle changes made legitimately in supporting a merge from unintended extra changes that break things.

It also separates changes you made to implement your functionality work relative to the branch point from the extra changes you need to have your functionality work relative to the merge point. With rebase, you get the opportunity to put all the code to implement a feature in one place.

Remember that the usual caveats about writing software apply: you're doing this for the future-you and future-team-mates who come along in a few months trying to make sense of it all. Make life easy for them.