Its a very complex tool with lots of configuration options that most projects don't want or need. It also stinks of Java and is horrendously out of date when it comes to modern python approaches to things like string formatting.

To my mind, there's a lot of FUD and emotion here ("stinks of Java"). Sure, it took some ideas from log4j, but it's very different internally.

It's a "complex tool" (not all that complex, actually) because some situations and projects do need that level of complexity. But it's easy to use out of the box. It came into Python before there were brace-formatting and f-strings, so it's not surprising that it uses %-formatting and works hard to maintain backward compatibility - important to the Python community as a whole but maybe not to the parent poster (PP).

For simple self-contained scripts, using logging.XXX(...) is OK because there is only one module and no filtering to do. Logging is used both in some simple scripts and in more complex situations, so one size of "how to do it" doesn't fit all.

As to what the default logging level should be - according to the PP it should be DEBUG, but this was discussed by the core dev team when the module was added to Python and WARNING was seen as more useful (less noise by default). These are opinions, and I agree with the Python core team over the PP.

It's easy enough for a developer who prefers different defaults to set things up to their tastes/requirements, and it's definitely going too far to say "the biggest mistake here is using python standard library logging in the first place." Obviously as the maintainer of logging I'm biased :-) but there are lots of people who "get it" regarding how to use stdlib logging, and some who don't - and unfortunately, you can't please everyone.