/boot/efi is a common choice for the vfat ESP filesystem, when /boot is some other filesystem — typically ext4 or zfs. This was perhaps more common when BIOS or hybrid bootloaders were still a consideration, either as a fallback or because the partitioning was already set up.
I’ve only just started moving my systems from a zfs bpool and tiny ESP, to all of that space as ESP on /boot, as a first step toward using secure boot at last!
That’s what I was going to link TL;DR: It’s weird that people separate /boot and /boot/efi into different partitions. Just having /boot is not only acceptable, it’s preferable since it’s just as good and it reduces the problem space. The main reason to separate /boot and /boot/efi would be because your ESP is tiny, like the one Windows creates by default.
It takes the file system code from Grub and transforms it into EFI drivers, so you could in theory convince UEFI to boot off something as exotic as ZFS using that. LUKS would probably be a major challenge since it requires user input to unlock, but I suppose the tools are there to make it possible.
I’m not sure this really changes the situation? The EFI firmware would still need a place to load this driver from, presumably?
So you’d still wind up with a small FAT ESP, and a separate other-fs boot, just like with grub. In the cases of NTFS or ext4 that might be the same fs as root, in zfs that would be desirable too but the grub driver has limited support for advanced pool features, so a separate boot pool is still typical.
I have not read the spec myself, though from prior discussion I am remembering that the spec itself doesn’t mandate a specific filesystem support, but FAT basically became kind of industry standard because of how simple it is to implement and probably some “sponsoring” by microsoft, or them mandating it or another MS-FS. Especially the latter is just a wild guess though.
In theory any firmware implementor could support other or additional filesystems to discover the EFI-executables/bootloader from.
Implemnting any FS in addition to FAT would require them to have a “bigger” chip to burn the firmware on, which would increase cost, for no to little use targetting a very small group of powerusers.
Implementing other FS, without FAT would limit the market reach to that small group of power users.
Both options are probably not sustainable outside of niche-markets we do not have regular access to.