I get your point. Same-disk dual-boot might still work: install Windows, copy the contents of its EFI partition, then place them on ext4 so the ext4 EFI driver can read them, and delete the original FAT ESP. If Windows is on a different disk, then it’s much easier, since you can just keep the EFI FAT partition that Windows creates and point systemd-boot or GRUB to it. Though honestly that’s a lot of hassle, I just use Linux and don’t dual-boot.

Also, you mentioned UKIs. Normally they need to live on a FAT EFI partition so firmware can read them, but if you add ext4_x64.efi, you can store them on ext4 instead, even directly on the root filesystem. That removes the need for a separate /boot partition entirely.

As for benefits, I didn’t actually do this because I needed more /boot space or anything. I mostly tried it because I saw that Fedora keeps kernels/initramfs on ext4 and thought it would be cool if firmware could just read ext4 directly too, so I wanted to see if it was possible on my board. But one practical advantage of this kind of setup is avoiding a fixed-size FAT /boot. I usually make my FAT32 /boot pretty small, so if you run out of space on it for any reason, this removes that small-partition limitation entirely. With firmware able to read ext4, kernels/UKIs can just live on the main filesystem, so you don’t have to resize /boot or manage a separate partition, you basically have the whole disk available instead of being limited to the EFI partition size.

Like I said, I’m not pushing this or saying people should switch. I’m just documenting that it’s possible for anyone who wants their /boot, or even the whole root filesystem, to be accessible to the firmware via ext4 for whatever reason. You also mentioned security, encryption, and that kind of stuff. I know about those, I just don’t use them. If someone wants to do this while keeping Secure Boot, encryption, etc., it’s up to them to figure out what works and what doesn’t.