Some things on how PCs boot the old fashioned BIOS way
A while back I wrote on how PCs boot and hard disk partitioning, which gave a quick description of the original BIOS MBR-based method of booting a PC (in contrast to UEFI booting). It's worth talking about BIOS booting in slightly more detail so that we can understand some constraints on it.
In practice, BIOS MBR booting goes through at least two and often three stages. The first stage loader is started by the BIOS when the BIOS loads the first 512-byte sector from an appropriate hard disk (which gets complicated these days) and then transfers control to it. Generally all that the first stage does is load more code and data from disk, in other words load the second stage. Because the first stage has only a few hundred bytes to work with, most first-stage loaders hard code the disk block locations where they find the second stage, and basically all first stage loaders use BIOS services to read data from disk.
The second stage boot code contains at least the core of the
bootloader, and is often fairly comprehensive. For GRUB, I believe the second stage
image contains the GRUB shell and menu system, various software
RAID and filesystem modules (such as the one that understands ext4),
and some other things. For GRUB, the second stage can't boot your
system by itself; instead it will proceed onwards to read your
grub.cfg, possibly load additional GRUB modules that your
tells it to, and then for Linux hopefully finish by loading your
selected kernel and initramfs into memory and starting them.
I believe that most second stage bootloaders continue to use BIOS
services to read any additional data they need from disk (for GRUB,
grub.cfg, any additional GRUB modules, and then finally the
kernel and initramfs). This means that BIOS MBR based bootloaders
are subject to the whims and limitations of those BIOS services,
which in some situations may be significant.
It's common for bootloaders to read data directly out of your
filesystem. This obviously means that they need to be able to
understand your filesystem and anything it sits on top of (such as
software RAID, btrfs, LUKS, and so
on). Since bootloader filesystem and so on support can lag behind
kernel support, this can leave you wanting (or needing) a separate
/boot that your bootloader can understand.
A certain amount of this is a lot simpler with UEFI booting. UEFI has a concept of files in a (simple) filesystem, real NVRAM variables, and a reasonably rich collection of UEFI services. This means that bootloaders don't have to hardcode disk block locations or have complicated ways of hunting for additional files; instead they can do relatively normal IO. Since UEFI will load an entire UEFI executable for you, it also eliminates the first stage bootloading.
Since UEFI booting is better in a number of ways than BIOS booting, you might imagine that an increasing number of machines are set up to boot that way. Perhaps they are for name-brand desktops that are preinstalled with Windows, but at least for Linux servers I don't believe that that's the case. Part of this is sheer pragmatics; the people putting together installers for Linux distributions and so on know that BIOS MBR booting works on basically everything while UEFI may or may not be supported and may or may not work well. Maybe in five years, server installs will default to UEFI unless you tell them to use BIOS MBR.