I agree, I don't think this is actually 'new' at all. We have had EFI Stubs, KExec/KSplice (Heads as a loader distro for example) and non-GRUB options for a while.
At best, this approach doesn't make the boot loader 'go away', it just moves that task to EFI. Which means you depend on EFI instead of GRUB. This isn't really different from say, U-Boot, where you have a bootrom (usually in the SoC or ROM) that does bringup, then U-boot as an intermediary, and then the Linux Kernel. Same deal with BSP and Coreboot, or Bochs or any of the other boot protocol launchers.
Maybe if their scope is the narrowest of all the scopes (only x86 and only UEFI 2.0 and higher and only specific distros) it might make sense, just to have it be invented in-house as a fake moat. But the end-user doesn't really benefit (as there is no change), and other distros are unlikely to care. You do get a dependency on IBVs and OEMs to implement their UEFI correctly, which most have a hard time doing as it is. And you can't re-use it anywhere else, except maybe SystemReady ARM servers.
At best, this approach doesn't make the boot loader 'go away', it just moves that task to EFI. Which means you depend on EFI instead of GRUB. This isn't really different from say, U-Boot, where you have a bootrom (usually in the SoC or ROM) that does bringup, then U-boot as an intermediary, and then the Linux Kernel. Same deal with BSP and Coreboot, or Bochs or any of the other boot protocol launchers.
Maybe if their scope is the narrowest of all the scopes (only x86 and only UEFI 2.0 and higher and only specific distros) it might make sense, just to have it be invented in-house as a fake moat. But the end-user doesn't really benefit (as there is no change), and other distros are unlikely to care. You do get a dependency on IBVs and OEMs to implement their UEFI correctly, which most have a hard time doing as it is. And you can't re-use it anywhere else, except maybe SystemReady ARM servers.