As for the likeliness of the scenarios, I'd also like to hear feedback from Microsoft. But at least I can list a few scenarios I am aware of:

• Everything works flawlessly. Hopefully the most likely one
• One of the updates runs into a defined error, which is logged to event log and reflected in registry values. You are not off worse than not trying
• Bitlocker Recovery key required: This can only happen if Bitlocker is used and uses PCR7 in TPM in a key protector. In two possible scenarios: 
  • (1) Measured Boot cannot properly reseal the PCR after adding key to DB or KEK database.
  • (2) One of the variables does not persist on boot, but the PCR has already been resealed to the new value
  • In any case, this issue can be totally avoided by suspending Bitlocker before the attempted update for a few reboots. When resuming Bitlocker after the changes has happened and the system rebooted, the new PCR7 value can be obtained and used to re-seal PCR.
• The system freezes/hangs and requires a full power cycle to boot up again (with the old keys). Only a nuisance when deploying the changes remotely.
• The system reboots after apparently having applied the update but one of the values does not persist. As the bootloader is replaced after the first reboot, this will not cause any Secure Boot violations. It may (see above) result in Bitlocker Recovery key as PCR7 has been sealed to new keys but actually present keys are old keys.
• The system reboots, has applied the keys, but the boot fails with a Secure Boot violation due to a firmware bug. In that case, enter Setup, restore the values back to setup defaults, boot up again (again taking care of BitLocker as the PCR7 will not match or was cleared due to the UEFI reset) and best do not try applying the keys before getting the firmware updated (if available)
• The system reboots, but then is "bricked" (freezes on every reboot even before being able to enter the BIOS/UEFI setup). On some old systems, this has been a known, very rarely happening issue for any UEFI variable updates (not just DB/DBX/KEK), when the EFI variable store is almost full. There have been reports about this issue years ago, on very old firmware (think about the age of when Windows 8 came out), only happening very rarely, but if your machine is affected it could have as well happened during a normal DBX update. Probably less likely to encounter this in a corporate environment as machines are newer. And I would assume Microsoft would by now have applied safeguards not to apply any UEFI variables updates (neither DBX updates nor the new Secure Boot Certificate updates) on such devices if the UEFI variable store is almost full.