I've been reading Elijah Newren's blog posts on optimizing git's merge implementation. To enable the optimizations, they added the new "ort" merge backend.
Crucially, it can merge without touching the working tree or index. These two commit messages are nice reads:

• gitster/git@fe1a21d526 (fast-rebase: demonstrate merge-ort's API via new test-tool command, 2020-10-29)
• gitster/git@6a5fb96672 (Change default merge backend from recursive to ort, 2021-08-04)

This sounds like we're one step closer to getting some of git-revise's features in core git.

git-rebase (and git cherry-pick) should move towards only touching the worktree when needed, as this comment suggests.
If that becomes reality one day, the main difference is conflict resolution (with git-revise using a temporary file (?).

Another difference is that git-revise never reparents a branch (i.e. it does not add new commits from upstream).
Maybe it makes sense to split git rebase into git rebase (for reparenting) and git revise (for history modification), like reset/checkout split off restore/switch. Ofc that's another discussion on the Git project.

I just discovered git merge-tree which has apparently always been able to merge without touching index/worktree; I wonder if this is powerful enough to replace our use of git merge-file. (I'm not sure what's the difference to the ort merge, probably this one doesn't detect renames etc.),
git merge-tree can't change commit messages, so it's not usable for git-revise.