Thank you for the PR.
I see your point and I'm not against this, just some points to discuss / consider:

1. if sombody (most of the time) will have logger for the framework on info level won't see any log message regarding what happened. It will just retry but there will be no info about that the conflict happened whatsoever. So the reconiliation will "silently fail". Maybe for this case just rather log a short log message without stack trace that this happened? thus:
   like:

log.info("Conflict while updating custom resource, but next reconiliation is imminent").

Would this help in your case?

2. Note that usually retry is always in place (well it is considered a bad practice if turned off), so in most the cases it will retry this error right after the conflict anyways (regardless if reconciliation is imminent (other event received meanwhile) or not).

3. another option I see is to have a dedicated logger, this where we log now the conflic we could have a dedicated logger:

private static final Logger conflictLogger = LoggerFactory.getLogger(ReconciliationDispatcher.class.getCanonicalName()+".conflict");

// omittes code


// modified log in this PR:
conflictLogger.info(
                "updateErrorStatus failed for resource: {} with version: {} for error {}",
                getUID(resource),
                getVersion(resource),
                e.getMessage(),
                ex);

Now you can change the log level of this logger to "warn" in your config you won't see these log messages, however we will be backwards compatible. (but maybe this approach is overkill)

Please let me know what do you think about these.