Earlier quoted context omitted.
If there are 100 servers but only one is needed to handle the user traffic, then 99% of those servers are considered to be "doing nothing" even if they are powered on and running software. At the end of the day, running that software is meaningless to the business and to customers.
I think the point was that "ready and waiting" is valuable to the end customer, even if it only makes a different later when they are doing something. It's kind-of like how firemen are valuable even when they are not getting calls, because they are available for low latency response instead of busy doing something else. The idea that this is just wasted computation is therefore somewhat disingenuous.
If load becomes too important for the SBC or close to capacity, wake the server, and perform a handover once it's up. You can either hold the packets and use the SBC as a proxy, or change your router's config to point to the newly awakened server (alternatively, just exchange IP or MAC addresses). With a bit of magic to avoid closing existing connections (I believe home ISP routers should keep NAT connections open if a port forward is changed), it would work. Obviously it's even easier with a proper load balancer.
edit: actually even a router might be able to handle low loads
There seems to be surprisingly little interest in this (closest I found was https://github.com/kubernetes/kubernetes/issues/89271 ).
So yeah, it's still wasted power and computation in my opinion. "Ready and waiting" should not take 100W per server, but be closer to 0.1W (WoL), or lower if managing state from a central node. I guess it's not worth optimizing for most people, and big cloud probably does something similar already.
In a way, it's a bit like big.LITTLE with additional latency: small, power-efficient vs big, fast, inefficient for small loads.