It's not just a simple flag - it's basic stuff like for example which clock pin is mapped to which clock consumer(s), which GPIOs on which pins are mapped to stuff like LEDs, the power/reset switch, which hardware interrupt line is mapped to which GPIO... all stuff that's best kept inside the BIOS where the manufacturer can easily patch it if needed in contrast to the Linux kernel with its notorious difficulty to get stuff accepted into mainline, much less into a kernel that actually runs on users' computers - think LTS users, for example. I can take a 2010 kernel and it will likely run fine on a recent x86 machine, but if I needed to wait for motherboard support to ship in kernel, that would be not very cool.
Yes, something like FDT would be nice but even on the relatively small ARM space it has its fair share of issues - I don't even want to think about having FDT in mainstream x86.
Generally I agree with you, however there is one thing that cannot be done without a RAM-persisted firmware: any kind of power management. It's highly dependant on the specific chips (sometimes, chip revisions) on the motherboard, and while integrating even ultra low level stuff into the Linux kernel might help there, we see the consequences of doing so in the Android world: manufacturers do not have the time/money to get their code in a shape that's going to be accepted by the kernel community, so they fork it and the users are screwed.