The fact remains that when we think of debugging tools we tend to build monolithic debugging environments rather than unix-style primitives that do one thing well. Thinking deeply about when prints work best and how we can ameliorate their drawbacks is a fertile place to change this. A couple of concrete ideas:
a) For a while now, I've experimented with editor macros to comment/uncomment code that insert a special marker after the comment leader (like say //? for C++ or Java) that allows me to programmatically distinguish real comments from commented-out code. An immediate benefit is that I can select large ranges of text and enable/disable prints without messing up interspersed prose. A more subtle benefit is that it lets me leave prints in version control for weeks of time and watch which prints I use most often when debugging. I've also experimented with a couple of subsidiary experiments: a1) highlighting //? comments differently (much less saliently) than real comments, so they don't bother me as much in my editor, a2) having my comment macro set/increment a per-line counter which provides even more fine-grained telemetry about how my codebase is used. It's illuminating to save all the prints you made while debugging a problem that ends up being just a one-line fix. Even if you end up deleting all the prints immediately in the next commit. And if you think it makes merging harder, well that's just a task for another simple unix-like tool: to filter out commented-code before merging, and add it back in afterward.
b) A big problem if you do a lot of printing is to find the right prints that help you debug your problem now. Print too much and it becomes easy to get lost in all the verbiage. I've tried battling this problem with a 'zooming editor' which reads a potentially huge log but displays only stuff at the highest level of abstraction, letting the user selectively click on lines to expand more and more detail around them. I can even bring up this zooming editor automatically when my program dies in debug mode: http://akkartik.github.io/mu/html/090trace_browser.cc.html [1] This is an incredibly useful tool, because it turns a two-sided problem into a one-sided one; instead of having to walk the tightrope between too much logging and too little I can just log everything and poke at it in my leisure.
Not all these ideas are good. I gave up on a2) above after a few months, for example. But there's lots of room for questioning conventional wisdom and trying new things.
[1] Details on my literate format: http://akkartik.name/post/wart-layers