'git reflog' is your friend as it keeps a history of local operations, then you can do a 'git reset --hard HEAD@{X}' where X is the point in your reflog before the rebase started.
While this is true, it's also more of a crutch. You should practice to predict, before your rebase, what conflicts your are gonna hit. And aborting a rebase is a significantly safer option. I would only recommend reflog when you rebased (on) the wrong commit and you want to undo a successful rebase.
I do the same unfortunately. I have a cheat sheet text doc called Git Shit that I use to attempt to keep track of the myriad ways to do shit in git. What a lot of people don't understand is that one wrong move and you've LOST ALL YOUR WORK! Which I have done enough times that I take the safe way that you describe a lot of times.
As long as your source and target branch are present on the remote (i.e. github/lab/whatever) you probably don't need to trash the entire repo. Just `git --rebase abort` and if you're halfway through a rebase just delete your local source branch and re-fetch it from the remote. That's my process anyway if I somehow lose track of what I'm doing. Or sometimes as a reference I just open the remote branch in github/lab/whatever directly so I have a little cheat sheet, since the "current/incoming" somehow always confuses me.
Before I rebase, I always create a "backup" branch (`git branch backup`). Then if I mess up, I can always reset back to it (`git reset --hard backup`). Maybe better than trashing and re-cloning :-)
Fundamentally, this is my fault - I don’t have a good mental model of git, and even when I do have a solid understanding of what I’m attempting to achieve the actual repos/situations I find myself in rarely line up with the examples to any useful degree.