The mechanism of using a BeanPostProcessor to populate the job registry is problematic as it introduces a dependency (the JobRegistry bean) in the JobRegistryBeanPostProcessor. Having dependencies in BPPs is not recommended and might cause issues like #4519 and #4489. Here is an excerpt from the SF docs:

If you have beans wired into your BeanPostProcessor by using autowiring or @Resource (which may
fall back to autowiring), Spring might access unexpected beans when searching for type-matching
dependency candidates and, therefore, make them ineligible for auto-proxying or other kinds of
bean post-processing

It turns out this has always been problematic in Spring Batch, and only made visible after the log level change in SF #24092. This issue is to deprecate the JobRegistryBeanPostProcessor in favor of a SmartInitializingSingleton (like suggested in #4521) or another mechanism that is not prone to trigger early initializations of beans.