Think slf4j as API, and logj4 as implementation. slf4j has multiple implementations, e.g. logj4, logback, apache common logging bridge, so you can swap implementation easily without change your code(except configuration)
It's great because you can use whatever backend you're comfortable with in your setup. Are you a JUL guy? Great, configure JUL then.
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.
I just switched from Logback to Log4j2 for an application and since I was using SLF4J, there were no code changes required.
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.