You also can't be confident that a debugged program is in a natural state without restarting it, at which point the re-setting of the breakpoints and scripting

You also can't be confident that a debugged program is in a natural state without restarting it, at which point the re-setting of the breakpoints and scripting you did in the last invocation - or saving and loading what you've already done - is a pain point. If all of this is quicker than recompiling/relaunching, then IMO there is a second bug in a lack of effective logging. Most bugs I create are for simple reasons and can be found by scanning the first error logs. If I add print statement debugging because I couldn't then they'll often be adapted into additional logging. If I use a debugger for this as my first tool and don't add logs, I'll have to do it again next time, too[1]. If the bug is not a simple one and is not a structural bug, there's a decent chance it's something debuggers deal with poorly: data races, program boundaries, non-determinism, memory errors. If it's something that can be found by calling a function with certain parameters, it's a missing test case. So the times I find debuggers to be worth it are after I've already decided it's a difficult yet uncommon bug. So I use them with despair. [1] If I fix it with a debugger and then add the logs, I still have to prove it gives the right output when it fails.