The way you describe "exploratory debugging" make it sound very close to binary reverse engineering: you put breakpoints/tracepoints at strategic places, run the program repeatedly, dump strategic memory addresses ... in an attempt to get a grasp at what the program is doing.

This is what you do when you can't rely on file names, variable names, function names, types, and comments.

A codebase that make this the fastest possible workflow probably has some important design issues.