Maybe it was just that the boot environment was simpler
in older systems, without the need to load kernel modules
or support multiple locations and means of access for
the root?
Older systems had fewer choices. On the PDP-11 you had Q-Bus or Unibus.
You booted off a small selection of disks that converged to MSCP(?), so
there was THE boot environment and THE driver and THE filesystem. And
the kernels were often tuned to be exactly what the machine needed.
The VAX, Sun, hp, ibm, etc continued this early trend. Though the boot process
was still fairly narrow, with a limited list of supported boot devices.
In large part this was because the machine was exactly the same every
time you booted.
But with USB, PC Card, CardBus, ExpressCard, SCSI, Thunderbolt,
and a host of other removable technologies with a dizzying array of
cards, like PCI, ISA, etc, the game changed.
Also, the number of environments that a FreeBSD GENERIC[*] kernel
can boot in is huge due to combinatoric explosion due to three or
four boot environments, vm alternate startup paths, several supported
root file system, BIOS, UEFI, OpenFirmware, u-boot, coreboot, etc
as well as several thousand supported boot controller devices, things
got complex, despite there being several common interfaces that made
things simpler. I'm running a summer of code project this year to help
tame the combinatoric explosion to provide better test coverage because
though attempts were made to make things the same, variations exist that
can cause unexpected breakage in different environments.
Warner
[*] I use GENERIC here as a catch all, including the more recent MINIMAL
kernels that try to include just the core functionality, and omit the vast
majority of drivers. Linux has similar issues, but more, and also solves
them in many interesting ways... But I'm the FreeBSD boot loader guy
in large part (though there's others that work on it), not a Linux person.