Hard coded logger instantiation in a library is anti-pattern. Whoever is using your library usually has his own opinions on how much of your stuff he wants in logs.
Second, it is not like each java program would be inventing its own super complicated xml like logging configuration. It is pretty much always done the same standard way. Pretty much every java app uses one of two standard logging libraries and those libraries share the same API.
You can configure that standard API in xml, through properties file or in code and all three methods are basically the same thing in three different syntaxes. None of them is easier or harder then the other two and everyone is familiar with both xml and properties file one.
No one normally obsess about logging code too much. It is the least obtrusive easiest to do part of anything you can possibly work at.
For example, some changes even though very easy to implement are very difficult to push in production because of requirement of senior management approvals.
Also, best practices depend on the actual environment that you work on. For e.g. In one of the projects, the DBA team had very cool people compared to the server admins who were a pain to deal with even when we had all the approvals. So we decided to keep the configurations in a table and not xml, as changes could be pushed easily!