A similar option is to boot a kernel using the built-in EFI stub (CONFIG_EFI_STUB=y), embed the initramfs if you use one (CONFIG_INITRAMFS_SOURCE), and set the default command line with CONFIG_CMDLINE if configuring it via UEFI is too unpleasant. I boot like this.
Advantage: less complex than adding another layer (and dependency) with the gummiboot stub.
Disadvantage: relinking the kernel is more expensive than rebundling with objcopy, if you change initramfs with the same kernel often.
Disadvantage: it's not an option if you use a distribution kernel binary instead of building your own.
I actually wrote a UEFI boot loader a few weeks ago that loads the kernel, initramfs and command line directly from a file on the root fs. It uses the efifs project to let it load directly off of an ext4 file system.
It's nice to use compared with grub, just edit a file and reboot. I've struggled to understand exactly how the fedora boot system is configured, and which command I need to run or file to edit to get it reconfigured.
The extra step of running the command to generate the final output file has saved my ass many times since it checks for errors as well. Other than that command it's the same process isn't it? Edit /etc/default/grub, run command to validate and apply, reboot?
Not related to this change in particular, but: mkinitcpio is neat to me because it is one of the last pieces of bespoke distro-specific software that's stayed on my radar.
It used to be that distros had to come up with huge piles of distro-specific scripting to build a complete system, but the trend has been to create independent projects so that each distro doesn't need to reinvent things. Distros used to have a lot of custom bootup scripts, which have been largely replaced by modular components of systemd. For many distros, the scripts for creating the init ramdisk have been replaced by Dracut; but not on Arch Linux and derivatives, Dave Reisner's mkinitcpio is still going strong. And it's interesting that Arch is being a holdout with Dracut, when they were one of the first adopters of systemd.
Is there a good reason for this? The last I read [0], Dave didn't think that mkinitcpio was the way forward. I've since migrated my setup to use dracut and haven't looked back. Is it just inertia that's kept mkinitcpio alive?
Relatively straight-forward once you read up on alpm hooks [0] to make sure you're rebuilding the init at the right times. The wiki [1] has working examples that are drop-in dracut replacements for /usr/share/libalpm/scripts/mkinitcpio-{install,remove}. Dracut also makes it easy to build unified kernel images that can be signed for secure boot, which I never figured out how to do with mkinitcpio.
I do create my own "EFI stub" by embedding the kernel and initrd in a GRUB image as memdisk using grub-mkimage. Then I sign that using my own keys and copy it over to the EFI partition. One cool thing about it is that I can still adjust kernel boot parameters, or load entirely different kernels by mounting the encrypted LVM volume of I really need to. Using the kernel's own stub support this isn't possible, but at the end the grub image still a single self-contained bootable EFI executable file, just like the Linux stub.
Advantage: less complex than adding another layer (and dependency) with the gummiboot stub.
Disadvantage: relinking the kernel is more expensive than rebundling with objcopy, if you change initramfs with the same kernel often.
Disadvantage: it's not an option if you use a distribution kernel binary instead of building your own.