Thank you for the suggestion, Andres ... but as far as I can tell, the approach POI takes will have the same problem as the one I identified if you actually do route your log messages through the CommonsLogger implementation of POILogger.
The adapter approach works fine for actually getting the logging output piped through, and you can indeed make Commons Logging not required if you're really using JDK 1.4 logging instead. The problem, though, is in how the logging systems display the name of the class and method from which the message was logged – they go up one level on the call stack, and extract the class and method names from that. The problem is, when you use an adapter, that all messages appear to come from the log() method of the adapter class, not from the method that called the adapter. To get the display right, we'd need to teach the logging implementation to go one level further up the call stack than it normally would.
For the purposes that the POI website claims you would ever use logging in POI (just for debugging POI itself, not for production tracing) this is probably not a big deal ... you're probably staring directly at the source code, or using the system out logger (which doesn't do this at all) anyway. It matters more for a webapp where you want the INFO and WARN type messages to be logged to the same place as all the other messages from your webapp, with correct descriptions of where the logged messages come from.