Well that wouldn't really work without the PCIe devices also storing the configuration in NVM. If I plug a x16 device into a x4-only slot (as is typical for the third PCIe x16 slot on motherboards that have it), the device needs to know it has to only use 4 lanes, not the full 16.
Ok, so say the controller has some way to tell the devices to save their state, and when powering on they all read from NVM and can just go on talking with each other right away, no further initialization required. Yay!
Except then you power off your machine, and swap that GPU for the new one you bought from your friend. Now the new GPU has the configuration from your friends motherboard, and your bus controller has no idea about this new card... so this is doomed to fail.
Of course this could be worked around by querying the bus for the devices we expect to be there... except that's the initialization step we were trying to avoid in the first place...
EDIT: Ah, sorry, you're saying the enumeration/scanning for changes is what takes most of the time?
As for the software: Hibernate is storing that initialized state.
How much time would something like that take compared to initialization?
Why can this not work?
Hibernate (suspend to disk) used to be slow with spinning disks. Even with SSDs, if on a 6 Gb/s SATA bus hibernating my 32 GB laptop would take 32 GB * 8 / 6 = 42 seconds, probably more. And 42 s to resume. My laptop goes from power off to login and Gnome loaded in less than that time. Of course it takes much more to open all the programs I need. That's why I suspend to RAM. Push a button to suspend and less than 10 s to be working again. By the way, it takes extra seconds for the laptop to connect to the Wi-Fi access point or to the ethernet switch. IMHO it's not fully usable until then.
People do it with VM's, too. I think you were aiming for something physical with no extra software. That was closest thing I could think to it.
Developer errors? Not enough testing?
It's to limit the complexity of suspend/resume that a lot of OSes will do things like reinitialize all drivers (e.g. unload/load kernel modules) to try to get the whole system into a known state, but this takes time.
Relatedly, hardware can be added (or enabled) between boots, so whatever conditional hardware initialization was done when booting may result in a state that's not quite accurate later. Furthermore, some of the state (e.g. anything involving system time) will always need to be modified after restore, and that's a state transiston that's less well tested (moving your clock forward hours or days may make a lot of software flake out).
Only if you never turn your machine off. Don't you power off your desktop every day when leaving work?
That's sort of how Windows quick startup works. It saves the kernel state after startup, and on next startup, it restores it (kind of like hibernating the system). Iirc emacs does something similar with its lisp runtime as well.
And because the BIOS isn't your only state-holder, anything with a controller on it inside your PC holds state, and that is basically everything today. Including external devices, like everything connected via USB (actually those have two controllers minimum, a USB controller which holds communication link state and a controller for the actual device function, like being a keyboard or mouse).
It totals to hundreds of controllers, and it simply isn't feasible to standardize a way for this entire system to somehow store an overall consistent runtime state. That is why plan B is taken: just re-establish that state every time. We call this process "booting" or "initializing".
