With "SLF4J configuration", I mean whatever configuration the logging
backend uses.
It is even "the SLF4J configuration" in a broader sense: you can query
SLF4J about its properties. It's just a subset of these properties,
namely the logging level of each individual logger, and you need to know
the logger's name in advance, but it's a queryable configuration all
right.


No it's not; the SLF4J Logger interface has no inherent concept of a level.  It has "isXEnabled" methods, but there's nothing to stop you writing an implementation that returns true (or false) for all of those.  You could even write an implementation that returns a logger with those methods randomly returning true or false each time you called it if you wanted to - SLF4J doesn't care. The fact that there happen to be different loggers for different names with different persistent configured levels in Logback is an implementation detail specific to Logback.

It's going to be a lot, lot easier if we refer to Logback loggers configured for Logback, so if you don't mind I'll quote you as if you had:

So for each logger that's configured for Logback, I want to create a JUL
logger with the same logging level as its Logback counterpart. This should
drastically cut down on the number of log messages created and thrown
away.

To get hold of the root logback logger you can use the following:

import org.slf4j.LoggerFactory;
import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.LoggerContext;
...
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
Logger rootLogger = lc.getLogger(Logger.ROOT_LOGGER_NAME);

However, oddly you can't then ask the root logger what children it has - it's stored as a private variable (List<Logger> childrenList) with no public accessor.  I don't know what the reason for this is (I'm also curious why it's a List - it looks like a Set to me, order irrelevant but no duplicates).  I see no reason why it shouldn't have a public accessor exposing an unchangeable view of this collection to allow the introspection you ask for - you could then recursively walk the Logger tree.  It would be trivial to branch logback in git and implement this.

Another approach might be to look at the Joran configurator for logback and add a listener to it as each Logback logger is configured that creates the corresponding JULI logger (if that's the right JULI terminology).

Obviously both of these solutions would be Logback specific, but that's unavoidable - there is no sensible way to add Logger introspection to SLF4J, it just doesn't fit the interface nature of SLF4J.