If that's the kind of UX you prefer, please consider filing a feature request against your git UI of choice. My point is that git itself already has the core capability, and how convenient it is to use usually depends on your editor. (e.g. in vim, dd to cut a line and p to paste it in a new position is a very quick way to reorder)
And my point is that all this 'core capability' stuff is not relevant to the discussion of good UI, similarly the fact that GitHub has Pull Requests doesn't help when it's bad UI that needs "stack" reinventing.
Case in point:
> dd to cut a line and p to paste it in a new position is a very quick way to reorder)
It isn't quick, you're just swiping the whole issue under the rug - first, you need the whole separate interface, but more importantly, this new interface is very primitive, you see close to no context, only some commit names, so it's not quick to find what to move and where because the content for those decisions is in a different place. Sure, you could add some vim plugin that expands it and adds per-commit info (what, you want to view the diff for all 3 commits you selected and DDed? Tough luck, you don't see the lines anymore! And even if you did, that's not this plugin), but then it's not your `--interactive` git "core" that does convenience
Like I said, if you prefer an integrated graphical UI, you can file feature requests against the one you prefer. What git itself does makes a lot of sense for the canonical CLI tool to do, though even then you can propose or prototype changes if you have ideas. This is how projects like jj started in the first place.