I took a totally baroque project setup (they just don't know WTH they're doing) with some JUL and some log4j, piped everything into SLF via the bridges, then configured a log4j backend (which I'm confortable with) and now I'm the only person in the project that actually has control over their logging and configures it to log into nicely separated files for application output, SQL statements and so on :-)
In an ideal world we'd all just use one log system, but Sun screwed that when they created the very unnecessary JUL back in the day. SLF solves the logging mess nicely.
If there is one logging engine to depend on that libs can use, this means less dependency hell.
Fighting it is a losing battle with how much traction it has among all the different libs.
Also consider the case of third-party libraries. I have dependencies in my application that are hard coded to log to about three different logging implementations. If they instead used SLF4J, the end user could choose whichever implementation they were already using in their app, instead of having multiple implementations or needing to redirect the output via an SLF4J bridging module.
Other useful tool for logging, that integrate with logback or log4j is sentry: https://github.com/getsentry/sentry
And to use it with java: https://github.com/kencochrane/raven-java