DAWs are programs that interact in near real-time with:
a. Hardware.
b. Drivers for that hardware.
c. FX programs, often in the same processing threads.
d. Samplers.
This is a lot more interdependencies than most programs have to deal with.
With interdependencies, each block of code has to maintain its current state of its end of each interaction. How well each does that is dependent upon the expected usage patterns foreseen by its designers. Maintaining state of realtime transactions is pushing that envelope, and when hardware is involved, it is also dependent upon how it manages saving its internal state between power-ups.
Thus, the state of the DAW is dependent upon a complex set of independent internal states. Any problem in one of those states can disrupt the whole operation, especially where they operate on a shared processing thread.
When ‘sleeping’ or ‘hibernating’, the theory is that all the information of those independent states is maintained. But that may not be the case, as the designers of any one of them may not have saved complete states, especially when hardware is powered down. When hardware is powered up again, it is not necessarily at exactly the same state as it was when it powered down, and even if all the software parts saved their states perfectly, the hardware may present in a way that may not be what the software expects.
When hardware is powered up, it goes through what is called a power on reset, which is usually triggered by hardware connections on each smart chip in it, whereas just pushing a reset button may only trigger a general input line that invokes a software reset, which is typically less pervasive. Settings are usually kept in non-volatile memory (NVM), and reloaded upon start-up. They will not necessarily be what is required to continue from where it was before power-down, as that may not be good if you want to do a completely different project with it.
The differences in those resets is why some hardware needs to be powered down, and left off for at least 30 seconds to let the power supply capacitors fully discharge, to get it to properly work after its firmware misbehaves.
Of course, sleeping the computer may not trigger resets in the hardware peripherals, but they may detect the loss of active assertion of communication protocols from the computer, and change their internal state accordingly. That change may cause the hardware to be less than ready to deal with software that, having come back online, may not be expecting to have to wait for the hardware, or have to re-establish its operating conditions. Sleeping and hibernation don’t deal with critical timing dependencies that may have been disrupted by their invocation. They deal with returning to the instantaneous state of the software beforehand. Timing dependencies become very critical when dealing in the millisecond timeframes of audio.
Hibernation may have done nothing to keep internal states of the hardware, and it may be dependant upon whether the driver kept track of internal states of the hardware, and its own, before the computer powered down. Again, it is dependant upon what the designers expected users to be doing with it, and to what events they programmed responses for.
So, is what you’re expecting in line with what everything was designed for? Is it realistic to expect that you can sleep or hibernate your computer with a session active and be able to continue afterwards? Maybe not for some combinations.