I don’t think this is a fair assesement. Though I agree with the use of machine parsable log formats.
The biggest challenges with logging are performance and compatibility. For the latter, it’s a case of when you use a framework or library, and you want logs documenting their activity. You can’t insert logs into their code base. So they need to already have log statements in place to debug them. But then, you need a generic log interface which you are still in control of configuring, so you can specify where their logs should go, what level to log at, if to log at all, etc.
This was the first drive towards a common log interface in Java. To solve the compatibility problem.
The former, that of performance, makes the compatibility one harder. Because certain interfaces aren’t powerful enough to support all the features needed for performance. This for example is why log4j2 has a new interface, and isn’t using slf4j. There were also issues at first where the implementation and interface were coupled, and when the implementation turned out to be too slow, it couldn’t be swapped out. So whole new decoupled interface to implementation were created.
At which point, things fragmented. So different libraries and frameworks used different interfaces and even implementation and that’s when all the log adapters came out to unify the fragmentation.
Now, going back to the article suggesting the use of a simple protocol. That is proposing a common interface. Already, it’s an interface that can’t support all the performance requirements, because protocol function calls will always evaluate the arguments. What if debug level is disabled, and you don’t want the overhead of the map creation and string concatenation of all the debug level log statements? And now someone creates a second interface, and we’re back at Java’s issue of fragmentation again.
Also, tools.logger already has such a protocol, though with a few more features. But its wrapped in a macro so that log statements only evaluate when necessary.
And finally, implementing performant and concurrent logging to a file with rotation isn’t trivial.
Bottom line, logging is easy for easy use cases, and hard for hard use cases.
There’s a reason why Google just came out with one more logging API for Java https://github.com/google/flogger