> it is very hard to actually lose work here, for three reasons.

The opposite is true, of course, for example: you move commits arround, start to resolve conflicts, and after a few steps you realize you can't, so when you

> you can bail out at any time. as aforementioned with git rebase --abort

Yep, except for all the work you've done resolving the conflict, that's "aborted"

> the old commits still exist in git’s object database, unreferenced but intact,

The best UI there is - some hidded data store you're, of course, intimately familiar with, so won't have any trouble getting data out of. Oh, wait, you didn't even know it existed? Tough luck, git gud to avoid data loss!

> botched rebase is a few minutes of you perusing through the reflog.

Unless, of course, your not that sharp to remember all the commits from their names and would also like to see the diff contents to connect to your code work. But that's just more minutes extra, not that big of a loss.

> there’s of course, the low-tech insurance policy: git branch backup-before-rebase

Finally some sensible advice, one that should be the default backup plan to save userst he trouble of wasting "few minutes" perusing the logs