I don't expect this to be a winning answer, but let me mention another use case that I enjoy:
First, I regularly use the standard recursive edit when I'm being asked for something in the mini buffer. Queries like a a complicated filename or object.access.path. Although completion packages and "thing-at-point" commands like ffap-* often make it easy to inout what you need without leaving the mini buffer, without having to remember or type it all, sometimes they don't. Recursive edit allows you to keep that mini buffer open, and go somewhere else, find the thing you're looking for to put in the clipboard to paste into that mini buffer once you have exited the recursive edit. Or perhaps to record notes, or to correct a minor typo that you notice along the way of a bigger query replace. Without having to re-enter all of the options that some interactive commands may ask for.
Recursive edit records your current emacs buffer and window, including the ordinary buffer that is attached to the mini buffer that you might've executed recursive exit in, and the Ema point/text cursor in those.
I go a little bit further, and save/restore the window configuration in let variables in a wrapper around the recursive edit call. Then when I enter the recursive edit, I can change window configuration quite a bit, and then when I return I magically get the original window configuration restored. Window configurations can be a little bit of a pain to Setup, I really like this.
Before I started using recursive edit like this to save/restore window configuration on water mounts to a stack, I use the commands that allow you to put window configurations in variables and registers. I still have those commands. And I believe that I still have code that creates a separate stock of window configurations. But I use recursive edits augmented to save/restore window configuration more than anything else. I probably start recursive edits more frequently from outside the mini buffer that from inside, just to get this window configuration safe/restore. E.g when I am editing a piece of code, and I realize I need to make a change to some other piece of code, perhaps move a chunk of code from somewhere else to my current position, I often just enter it, saving the configuration, go somewhere else in that same window or in a new window, grab what I want, and then exit the recursive edit.
This is a bit like using a hammer instead of a flyswatter, Since recursive edit is more expensive than just saving the window configuration. Although probably not that much more expensive, since window configuration can actually be fairly big. But it's good enough, easier to remember than having dozens of different stacks and variables for different types of data, and I don't think I've ever overflowed the stack. I rarely go more than six or eight levels deep in the recursive edits. As shown by the number of square brackets in the mode line.
At the moment I have only augmented recursive edit with the window configuration. But I have considered adding other state That gets safe/restored by my recursive edit wrappers. Perhaps Zoom factor.
Of course I have changed the standard key bindings for simple recursive edit To map to my fencer recursive edit.
by the way, something similar from the world of web browsers may help understanding of recursive edit:
While I was dictating this post (sorry for the speech related typos) I wanted to leave the post half finished, and go and check some emacs to see exactly what state standard recursive edit save/restores. so I opened up another Safari web browser window on my phone, found what I wanted, and then came back to the half finished post in the original window. Each browser window or tab maintains its own concept of what the previous webpage you visited in that tab or window was. Remember that emacs frames correspond to most GUI windows. And indeed you can switch to other emacs frames at any time. The recursive edit gives you the equivalent of the back page history in a web browser tab or page. Because mei users tend to jump around between buffers and change position within buffers much faster than people change webpages, rather than automatically and implicitly stacking creating such a stack of recently visited buffers and files, recursive edit allows you to explicitly record the places you want to jump back to.
