I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.
By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?
I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.
I think it just means inside your editor's terminal, where there's usually some modest integrations like it detecting a source/line reference and either jumping you there or at least making it clickable.
I cannot for the life of me get gdb to debug a remote in VS Code. The debugger runs, and breakpoints work and integrate, but the console is dead. '-exec print foo' does nothing.
Time travel to the late 70s and use the lisp machine debugger.
I always felt the drive towards mouse-driven tools in the PARC world (InterLisp/SmallTalk/CedarMesa) was actually a regression because of the loss of history ("how the hell did I get here?")
They also had a proper REPL, and the reason I stay with Java and .NET ecosystems, is because they are the closest we can get back to the Xerox experience, after the UNIX divergence.
(Time-travelling debuggers are OK, too, I guess)