Merges / conflict resolution in jj generally work much better than in git.
When rebasing a big branch in git with conflicts, you usually end up having to manually resolve conflicts in multiple commits in a row - in jj you just have to resolve the conflict in the first conflicted change, and it usually adapts subsequent changes automatically.
Overall, rebasing branches with conflicts used to be a chore for me with git, and is now mostly a nothing-burger. Of course, I don't know the exact details of your scenario, so I'm not sure if it'd help, but I'd say it's worth trying, esp. if it's a common pain-point for you.
Is this the case even with rerere in git?
My anecdotal experience is that I indirectly need/benefit from rerere much less often because I'm not usually resolving the same specific conflict more than once. I fix it the one time and then jj is rebasing a whole lineage for me, starting from the early commits, not from the single-branch leaves. That way I don't get "I rebased one branch and fixed this one already, but now I have to do it again for a second branch that shared the same conflicted commit as the first."
By contrast, git rebase --update-refs does not handle sibling branches but detaches them instead, and git replay hasn't had much TLC for UX yet. Plus, the last time I tried replay it was still obliterating commit signatures.