The problem is not software. The problem is people.
Rather than trying to explain the problem (which most people who work on logging struggle to see), let me outline how you determine when the problem is either solved or absent.
The problem is solved when people like me (a hands-on system architect who writes code and tries to make decisions on behalf of a number of developers) do not have to think about logging APIs, facades or backends anymore. When nobody in my organization has to spend time trying to resolve the conflicts that arise from different logging technologies (and different versions of same technologies) being in use in the same system.
We have an example of that in Java: the collection classes. For most bread-and-butter uses Java has List, Map and Set types that people can just use. They are well designed, well documented and you can count on them to be available at no extra cost. It is unusual for a non-mad() Java programmer to feel the need to introduce extra dependencies for simple lists, sets, maps etc.
You most likely are not going to feel the pain of logging chaos if you are writing a single application. If you try to make decisions on behalf of 50+ projects, some of which rely on an obscene number of libraries, that pain will manifest itself every day and you will re-live the same pointless discussions and get the same pointless advice over and over and over.
Hope this sheds some light on why I think what I think.
() there are idiots who depend on third party implementations where the types in J2SE would suffice.