It kind-of makes sense when you think of rebase as a composite command that does a checkout of the branch/newbase and cherry-picks the commits from previous branch.
Yes, it actually totally makes sense, but the issue is that if one draws the mental picture the wrong way the first time (and is left uncorrected), it's equally easy to draw the mental picture (i.e. of commits "flying around" from one branch to another) in the other direction too. That's what bit me
I don't even know how to check for mistakes here with my current employer (god speed to the code I wrote at my previous jobs). Unlike a merge, a rebase leaves no trace except in the reflog :(
I've been using git since 2008. I just learned a few weeks ago that I had the opposite understanding of what --theirs and --ours does on git-checkout during a rebase operation. (briefly: --ours is the branch you are rebasing onto, --theirs is the changes from the branch with the changes you are repeatedly cherry-picking into the new branch. see this answer for more detail [0])
I shudder to think how much I've screwed things up over my career as a result...
[0] https://stackoverflow.com/a/34260242/2492058