I'm a huge fan of UKI - it's part of the underlying 'magic' of ZFSBootMenu (https://github.com/zbm-dev/zfsbootmenu/). We ship a single EFI file that is a full Linux kernel, a semi-custom initramfs and an embedded command line. With that, we can fully support root-on-ZFS because we don't have to re-implement a complex filesystem in a bootloader ... like GRUB. Because we're not trying to re-implement ZFS (or any other modern/complex filesystem), we can ALWAYS be current. If a new version of ZFS is released, all we have to do is build a new EFI executable with that baked in to the embedded initramfs.
There are serious concerns with SecureBoot and being able to unlock your own bootloader - but UEFI itself is a nice universal base to target in 2022.
You can do the same just without UKI by using the same parts (kernel, initramfs + cmdline) as separate files. There's the kernel's EFI stub and other minimal bootloaders (like systemd-boot) if you need a more complete menu.
Creating and shipping a UKI means that people can just write it to a USB drive that has a vfat partition marked as an ESP. As long as the filename is BOOTX64.EFI, modern x86_64 hardware will automatically find and boot that if no other working EFI entries can be found. Since the kernel commandline is embedded in the UKI, there's no manual/error prone setup to be able to boot the file with any required/extra arguments.
ZFSBootMenu can also render itself as an ordinary initramfs image and maintain a separate copy of the kernel it's built against. These can be launched with some intermediate bootloader (e.g., rEFInd, syslinux or systemd-boot) or the kernel's built-in EFI stub can be run from the firmware. However, some Dell firmware seems incapable of properly passing command-line arguments to UEFI executables; a UKI that encodes its command line is needed on affected systems.
There are serious concerns with SecureBoot and being able to unlock your own bootloader - but UEFI itself is a nice universal base to target in 2022.