Go ahead: program to the log4j2 API instead of slf4j

It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.

Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.

Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.

For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.

Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.

The escape valve: log4j-to-slf4j

Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.

As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:

Message API

Lambdas for lazy logging

Log any Object instead of just Strings

Garbage-free: avoid creating varargs or creating Strings where possible

CloseableThreadContext automatically removes items from the MDC when you're finished with them

(See 10 Log4j2 API features not available in SLF4J for more details.)

Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.

SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.

Disclosure: I contribute to Log4j2.

Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.

Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example: