Which raises the question, how are these not print debugging? How are they better than print debugging?

I admit I don't know any of these tools, but I hope (1) they don't introduce another language than the one the project is coded in, (2) they let you put the logging statements inline in the code since otherwise the debug setup would be hard to synchronize to the actual code.

The situations I described are not particularly wicked, but rather normal debugging. If the bug is not trivial (in which case an interactive debugger can help finding it quickly), then the process is always to start with a global but coarse view, decide where the bug likely is, and zoom in on that partial view, requesting more details.

I doubt any automated system can help much there. Automatic structure printing might already not work for many cases since it prints too much data, or formats the data in a way that is too mechanical and not fitted to the task. Or in case of object-languages, the system does not now how "deep" it should print these structures.

I think automatic structure printing is a nice to have for simple situations with few structure fields. In practice I'm almost always fine with typing a printf line manually. I don't think that typing and modifying the line as I go would take the majority of my debugging time.

I use interactive debuggers myself, and I think they are faster in simple cases since there is no edit-compile-rerun cycle. But like all interactive GUIs, they are not (or only badly?) scriptable and automizable.

They are better than print debugging because they allow to even instruct applications in production without having to do any change to the application.

Stuff like DTrace and Intellitrace have OS level support to integrate with the application being instrumented, execute whatever actions are required and interoperate with the debugger. Intellitrace even goes as further as supporting time travel debugging.

Yes some of them, e.g. DTrace, do have their own little scripting languages.