I notice that, absolutely None of my c++ veteran colleagues (I asked only 3)  is a gdb expert as there are concurrency experts, algo experts , …
Most of my c++ colleagues
don’t prefer (reluctance?) console debugger. Many are more familiar with GUI debuggers such as eclipse and MSVS. All agree that prints are often a sufficient debugging tool.
 Actually, these other domains are more theoretical and produces “experts”.
 maybe I didn’t meet enough true c++ alpha geeks. I bet many of them may have very good gdb skills.
I would /go out on a limb/ to say that gdb is a powerful tool and can save lots of time. It’s similar to adding a meaningful toString() or operator<< to your custom class.
Crucially, it could help you figure things out faster than your team peers. I first saw this potential when learning remote JVM debugging in GS.
— My view on prints —
In perl and python, I use prints exclusively and never needed interactive debuggers. However, in java/c++/c# I heavily relied on debuggers. Why the stark contrast? No good answer.
Q: when are prints not effective?
A: when the edit-compile-test cycle is too long, not automated but too frequent (like 40 times in 2 hours) and when there is real delivery pressure. Note the test part could involve many steps and many files and other systems.
A: when you can’t edit the file at all. I have not seen it.
A less discussed fact — prints are simple and reliable. GUI or console debuggers are often poorly understood. Look at step-through. Optimization, threads, and exceptions often have unexpected impacts. Or look at program state inspection. Many variables are hard to “open up” in console debuggers. You can print var.func1()