They bumped up against modern considerations of plug-n-play. You'll see that it's the kernel which makes up most of it, the rest of it is quite small. If you wish to compile a kernel for your own hardware, you can slim that down by a _huge_ amount. I've managed to go from around 130 mb -> 25 on one machine.
There’s a lot of neat stuff you can do if you build your own kernel.
On my old laptop I had a small EFI partition with a 30MB “linux.efi” kernel. The initramfs that was included had busybox, wpa_supplicant, elinks, and gcc5. The idea being I could totally switch OSes without having to make bootdisks or worry about having an unbootable computer. You can staticly link all the modules and firmware too which is convenient IMHO.
Openwrt still fits on routers with 4mb of rom space because of this approach. The x86 flavor, for example, doesn't have keyboard and mouse drivers by default.
It allows me to boot my kernel and initramfs directly from the SPI flash chip that stores my laptop's BIOS (coreboot), which is very useful.
My goal is to decrypt my disk from code stored on the motherboard (and physically write-protected) but I'm not there yet because fitting everything on 7.6MB is not easy. I may try using a bigger chip, or use the SPI-kernel to check the signatures of decryption code stored on the HDD.
Why not just go the more conventional approach of having a small stage-0 non-Linux loader stored in ROM which can validate an entire kernel stored on disk? If your goals are solely around trusted boot chain it makes more sense to keep the trust root (initial bootloader and verification) as small and possible to audit as possible, right? Even the Linux kernel seems like a pretty big attack surface to keep in ROM
