Logging always has a tradeoff between utility and overhead. It would be great to log everything, but it would impact performance too much. So you end up with logging levels, categories, release-only logs, etc.

Pernosco has something for that too. Since it has replay capability, it can replay with more logging than the original execution had. So to some degree, you can have your cake and eat it too. It's not perfect: I think it requires some level of integration with a given logging system, it's not going to do the full I/O to send your logs to where they would ordinarily go (syslogd or whatever), and you can't log values with debug-only code that wasn't compiled into the binary. But it's still a large boost to the fundamental tension around logging.

One of the points of the OP as that a really good debugger does capture and show you "the whole sequence of events leading up to the problem".

It's totally understandable that people prefer good logging to traditional debuggers which really suck. But you have missed the point of the OP that much better debuggers are possible.

Those are orthogonal to each other and you should use both. But in development, a good debugger with data breakpoints, logging and conditional breakpoints is much more focused than an overly verbose log.

It's not overly verbose, and it's something you need anyway.

Overly verbose in the context of debugging. Logs almost can't be too verbose, because as you said, they should be able to tell you the sequence of events that lead to the error.