I had a developer on my project that had a tendency to run into an issue and find a library to incorporate to solve it, rather than re-purposing an existing solution in a library we already had. Combine that with dependencies having their own dependencies, when it comes to a version bump it can quickly become unmanageable figuring out they all interact and what is even safe to bump. Consequently I've always thought the fewer externals the better, and if you do bring one in make good use of it.
One of the dependencies (indirectly) brought in was SLF4J which has proved to be a god-send and dodged a bullet for me with regards to this Log4J issue (hey, a stopped clock is right twice a day, right?). The gist of library being that it's an API abstraction of a logging library, the implementation of which can be wired up to a JUL (or Log4j, or even nothing) at deployment. The developer in question had somehow completely wired it up backward by using the slf4j-log4j compatibility layer instead (intended for codebases that have already used Log4J to move away without actually having to change code) but somehow brought IN log4j-core and a whole heap of errors on the console. After he left and I was cleaning up the mess of dependencies I actually read library's documentation(!), kept the abstraction and re-pointed the implementation to use the library the EE application server already had (payara itself uses JUL so I could piggy back off that), now happy that logging actually worked and (perversely) there were less errors in the console.
Long story short, thanks to that developer who horded libraries I discovered http://www.slf4j.org/index.html which ended up reducing the dependency footprint by allowing re-use of something already available. Can't help but think that other people may now find the compatibility layer quite useful. The theory goes that you can just replace the .jar with news ones at runtime - no compilation required http://www.slf4j.org/legacy.html#log4j-over-slf4j .