When Log4j was written, and probably when SLF4J & Logback were written, propagating to child threads was probably the right thing to do: it would match the expected/desired behavior for most people. I don't believe this is true anymore. People who are developing applications on the JVM today aren't as likely to be spinning off random threads here and there. Instead, they're quite likely to be using pooled fork-join executors and things like Akka actors.
In these more modern architectures, MDC inheritance is a disaster: it leaks information and breaks application state in surprising ways unless you override every utility that ever creates its own threads in these ways. Where I work, we have a non-blocking application stack based on Akka (we're using Scala, but it would be just as bad in Java). We looked at patching all the thread pools to clear the MDC on thread start and concluded it was both infeasible and too error prone, so we ended up forking Logback and creating a jar that has no inheritance. It was surprising to us that random threads that had never run a job had Job IDs and User IDs in their MDCs.
I don't have any data to back this up, but I would guess that this kind of scenario constitutes the majority of new applications that are or will use Logback: MDC inheritance will be a surprising problem rather than a nice feature. (There's also a major asymmetry in the failure modes: leaking information is generally a much more dangerous kind of failure than losing context.)
I do believe there is a legitimate reason to maintain backwards compatibility here. My suggestion is that the user should be able to plug in a callback object in the Logback config indicating which keys should be propagated to child threads. This could be PropagateAll (legacy behavior), PropagateNone, PropagateRegex. I would suggest that the default should become PropagateNone, for the reasons I describe above, but making it configurable would probably make everybody happy and prevent more people from forking Logback (as my company has done, privately).