Inherent exploitability and power state machines
I believe the OP's OQ has been answered in comments.

I cannot add comments yet, but would like to add a few details about state-machines for anyone that links to this.

This is the minimal (pseudo)code for a running micro-controller:

[Power on]
1: Initialize(); //Clock and other hardware
2: Goto 4; //void Main()
3: "Crash"/unhandled Exception/activate watchdog timer/undefined
4: NOP; //NoOPeration = do nothing; uploaded user code goes here
5: Goto 4; //User code typically runs in an infinite loop
6: Goto 3; //void Main() does not typically ever return


As long as the infinite loop is sustained, the controller is either running user code or "idle". The article the OP linked shows the idle bubble sub-texted with "wait for interrupt". In my experience with micro-controllers, there is no "state" for idle; idle just happens when there is nothing else to do.

The user code may, at any time, detect that it has nothing to do and tell the processor to wait for interrupts and/or go low-power.

WFI(); //Block execution until an interrupt fires


and/or

LOW_POWER_REGISTER &amp;= 0x01; //Physically power-down peripherals and reduce clock speeds


If desired, the user code may enter a custom or specific low-power mode and then, also, WFI(). WFI() has a very high chance of saving power since it suspends the user code, but may also invoke one or more integrated hardware power-saving features.

The interrupt that wakes the controller will be responsible for restoring any power states that leaving WFI() does not automatically restore. Typically, WFI() is used to pause until one or more input pins change. A watched "pin" can be actual solder terminal, or attached, internally, to peripherals like a timer.

I could not define "inherent exploitability," even with Google's help. The real issue with power state transfers taking too long is data loss. If asynchronously-received data is what wakes up the controller, a portion of the packet is lost before the controller is even awake. Sending a do-nothing "wake up" byte from the host before the actual data is light-weight and ensures that any receivers are awake and ready to receive.