There are some problems that can't be solved by printf debugging. They include:

-GPU Performance profiling: All your commands are async and appear immediate, teasing out performance characteristics takes a massive suite of tests and may not even reproduce your issue.

-Thread concurrency issues: Adding a printf can actually make these bugs disappear as printf usually has some sort of memory fence or flush semantics that change behaviour.

-Platforms that can't handle large amounts of trace logging: Sony PSP was one of these where each printf() required the tcp ack before the buffer would clear after a trivial amount of logs.

One of the core tenants of comp sci and technology in general is building on what came before. That's where our productivity gains come from. Not taking that approach is a dangerous mentality that can have serious implications on your velocity and agility and is not a choice to be made lightly.

You must have only worked on toy applications before.

Because debuggers are essential on any non trivial application.

Recently I was working on an embedded platform which had no debugger support at all. There was some On-Chip debugger option, but it required some soldering and hacking some jtag cable, still too lazy.

Despite the laziness, I ended up implementing gdb support for that platform, over it's normal serial port: https://blog.cesanta.com/esp8266-gdb

Go at least has stack traces with no extra tooling, which is a big deal. Anyway, the more tools the better; you're gonna miss them when you need them most.