I guess that shows how unfamiliar I am with UEFI boot Fedora. You would encrypt /boot to ensure that your boot images have not been tampered with, or config files haven't been read by somebody other than the end user.
Encryption != integrity/authentication. The only thing encryption guarantees is that the data is not visible, not that it hasn't been tampered with. Usually, dm-verity or dm-integrity is used for what you're asking for. Android uses dm-verity, if I remember correctly.
Or measurement and attestation via TPM2.
sd-boot still wouldn't work out-of-the-box though, due to /boot being xfs not vfat and firmware typically not shipping with xfs drivers.
If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used for /boot in Fedora, by default.
We could that by using vfat for /boot. Or by shipping & using xfs.efi, simliar to how apple ships & uses apfs.efi to boot macOS from apfs filesystems.
Is there a notable benefit to using that over GRUB2, which already has support on both UEFI and BIOS?
Less complexity in the boot chain, mainly. But the EFI drivers would need to be signed by MS, I think? That would massively complicate things.
I believe that to be correct, of could Apply has control over that for their platform, you'd also need to load them some how, I'm guessing sd-boot could try loading/locking if it can't read a file system... suddenly things start to head towards complexity again.