The Emacs manual node Recursive Edit explains the phenomenon. In a way it's like having another editing session (typically temporarily), with the same buffers etc. available (for the most part).

That node of the manual gives one example of how or why you might use it: you can use C-r to pause aquery-replace, then make some editing changes or search around a bit, visit other buffers to check things, etc., and then end the recursive edit and resume query-replacing where you left off.

Another place you might run into it is in some commands that use the minibuffer. Some such commands might prompt you for something but let you use commands while you are in the minibuffer which, themselves, might ask you something. The second prompt opens another (recursive) minibuffer "on top" (in the same place as) the first one. Answering that second prompt exits that recursive minibuffer, returning you to the original minibuffer so you can finish answer its prompt.

If you find yourself in a deeply nested minibuffer, as is shown in your screenshot, it's an indication that you probably did something that accidentally opened a recursive minibuffer. For example, maybe you used C-r during query-replace and you never resumed that query-replace; then you started a new query-replace etc.

Because this can be confusing, especially for someone not used to it, variable enable-recursive-minibuffers is nil by default. But some commands bind that to non-nil while they ask for minibuffer input (again, to allow you to use commands that might need to ask you something).

To jump back to the top level (no active minibuffer at all), you can use M-x top-level. To pop out of the current minibuffer level you can use C-] (abort-recursive-edit).

The Emacs manual node Recursive Edit explains the phenomenon. In a way it's like having another editing session (typically temporarily), with the same buffers etc. available (for the most part).

That node of the manual gives one example of how or why you might use it: you can use C-r to pause aquery-replace, then make some editing changes or search around a bit, visit other buffers to check things, etc., and then end the recursive edit and resume query-replacing where you left off.

Another place you might run into it (well, it's mostly the same kind of thing) is in some commands that use the minibuffer. Some such commands might prompt you for something but let you use commands while you are in the minibuffer which, themselves, might ask you something. The second prompt opens another (recursive) minibuffer "on top" (in the same place as) the first one. Answering that second prompt exits that recursive minibuffer, returning you to the original minibuffer so you can finish answering its prompt.

If you find yourself in a deeply nested minibuffer, as is shown in your screenshot, it's an indication that you probably did something that accidentally opened a recursive minibuffer. For example, maybe you used C-r during query-replace and you never resumed that query-replace; then you started a new query-replace etc. (It's also possible that some code you are using mistakenly leaves you in a recursive edit.)

Because this can be confusing, especially for someone not used to it, variable enable-recursive-minibuffers is nil by default. But some commands bind it to non-nil while they ask for minibuffer input - again, to allow you to use keys/commands that might ask you something.

To jump back to the top level (no active minibuffer at all), you can use M-x top-level. To pop out of the current minibuffer level you can use C-] (abort-recursive-edit).

There's no requirement to end any given level of recursive minibuffer. You can stay in a recursive edit forever, until you quit Emacs, if you like. But there's generally no reason not to exit a recursive edit when you are done taking that side trip.