It works in my test, but while I said I really don't mind for the future JUL or System.logger, do you think it is wise to replace JUL with System.logger as part of the deprecation per default?
It would be good to offer the System.logger variant, but keep the JUL logger as default (since you didn't delete it (and if you would, I wouldn't have approved the PR))

Especially as we stated this including and mentioning even the level

• Provide a logging implementation for the driver to use. Java logging framework {@link java.util.logging} with {@link Level#INFO} is used by default.
• Callers are expected to either implement {@link Logging} interface or provide one of the existing implementations available from static factory
• methods in the {@link Logging} interface.

I don't think it's too hard to construct a scenario in which people are relying on that, and they will see a bit of a surprise, without warning.

In the end, I leave it to your judgement.
Maybe I overthink the switch, but we have seen the oddest issues with changing the logging in the core product, and the issues created in some constellations with bridges, fascade etc being on the class path or not (both variants caused trouble).