It seems that "git rebase" has additional fallback logic to deal with merge failures:
Falling back to patching base and 3-way merge...
What is it doing there, and how would I need to invoke my cherry-picks to get the same behavior?
Probably the right solution is to just not attempt to represent a rebase as a series of cherry-picks, but it would be nice if this were possible, since I can then deal with both rebases and arbitrary collections of changes using the same flow.
Most git rebase commands actually do run git cherry-pick.
The fallback you're seeing occurs from the one form of git rebase that, for historical reasons, doesn't use git cherry-pick. That one form is used when you invoke a non-interactive git-rebase and don't use any of the options that make it use new-and-improved rebase-invoking method.
The old form usually produces the same effect. It consists of using git format-patch to turn each commit into a patch, and then using git am --3way to apply all the formatted patches. The --3way option tells git am that, if the patch cannot be applied blindly, it should use the index lines in each formatted patch to achieve part of what git cherry-pick would have done automatically.
If you want rebase to use git cherry-pick directly, you may:
-k option, or-m option, or-s strategy option, or-X extended-option option, or-i or --interactive), or--autosquash option, or-p or (Git 2.18+) -r option.