There is a time and space for print debugging or its equivalents, like when debugging very low level code, or when debugging rarely occurring problems.
However, using a real debugger is extremely powerful when it's available.
Definitely, printf debugging is a tool left for the few cases where a proper debugger, jtags, intelitrace, dtrace, jmx, flight recorder, and other similar technology isn't available.
With a graphical debugger, how do you produce a log-trace of what your program did?
How do you show a table of just the information you need, to help you find a bug? What if the table is a join of multiple datastructures from distinct locations?
How do you, after stepping forward through the code until you reach a certain configuration, make a small modification to the logic, so that you can replay from the start with the intent to reach a slightly modified configuration?
Are graphical debuggers on par with simply print debugging to notify when a particularly complicated situation occurs that can only be described by a complex logic?
I mentioned already a few possibilities, as I was expecting that question.
Edit: Since you edited your question after I replied, all those use cases are still covered by intellitrace, dtrace, flight recorder, jtags, with the benefit of not having to recompile the code.
Naturally you can come up with wicked examples that those tools don't cover, then again they will be most likely irrelevant for the large majority of devs.
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.
