So, I happen to like extensible logging frameworks myself and would prefer to use them over the standard library's any day.  That said, prospective customers registered very strong preference for minimizing the total scope and number of outright dependencies due to potential version conflicts with application-specific packages that may be needed—e.g., Prometheus requests SLF4J version X, and the core application that is using Prometheus requires version Y, while the class loader takes a "first loaded class wins" resolution strategy, which can lead to nondeterministic problems.

My request to you is, can you please explicitly ask your most critical of stakeholders to see if want that here?  Unless Phil Calcado or someone else notable wants this, I would say "no" to the inclusion of SLF4J—especially since we are only using it in error reporting workflows, not in standard workflow tracing.

Another complication with SLF4J (not an insult against it) is how it decides what emitter strategy this instance of the logger would use.  This is configured, IIRC, through Java properties or nondeterministic classpath resolution as a fallback.