I think it should very much not be in the SLF4J API because it's not the right
level of abstraction - it mixes logging a statement (SLF4J's responsibility)
with controlling what actually happens to those log statements at runtime (the
implementation's responsibility).

As I see it the problem here is that code that should not be taking
responsibility for setting log levels is doing so. Adding the same function to
SLF4J would just encourage people to commit this kind of error using SLF4J as
well.