Who has a separate /boot. One uses whatever filesystem one wants. The fact that GRUB is supposed to just work tends to make this the default setup. Then one gets dark warnings about how XFS might not work if the file was only written to journal and XFS did not get around to flushing the journal to disk. The illusion breaks.
I have RAID1 setups for most servers and there also GRUB is inconvenience, although it's still possible to make it work. In the past it used to flat-out fail trying to grok how the RAID is set up, probably because of reasons that don't directly relate to GRUB but to the os-prober. But if you now say "So why put /boot in the RAID? Just mount a partition on the disk separately", I say "But I have 2 disks in my RAID1. How can I mount /boot twice and have the files appear in both disk's copies when a new kernel is installed by my distro's package?"
If we had a separate 100 MB region set aside and understood by GRUB, it doesn't matter what RAID we have, GRUB scripts could be easily written to see that you have N disks, and to install the kernels on all the drives in such a way that it doesn't matter which one of them fails, and all of them can get a kernel up and going because everything is duplicated on all the drives.
The question here is not how to engineer around the issue using the design we have (separate /boot, ext2 filesystems, using RAID1 for /boot and say RAID5 for /), the question is that the design picked by boot loader implies that it needs to have almost the same capability as fully booted kernel. And that, IMHO, was a stupid choice.