If I told you the biggest culprit is component xyz, that would be a guess.
I can easily think of a myriad of SW explanations why Windows devices might have worse battery performance than Macs on similar HW that are not "polling": too long of a boot sequence, too many running processes, inefficiencies in the OS kernel in scheduling, memory management or caching, quality of ARM port, bugs in device drivers, bugs in the web browser, bugs in other applications etc. etc.
Windows is an eminently pluggable system, fully able to take advantage of low power states in hardware, ACPI, etc. Fundamentally there is no reason for it to be a power pig. But it is, because the choices made in it were made for a different world of computing.
Yes, that's why I wrote it's an obvious guess.
> Windows has an enormous amount of legacy code, and behaviors that were perfectly fine even just a few years ago now can devastate battery life.
Ok, you seem to know this. Can you tell us now EXACTLY what legacy code is there in Windows that causes the "busy-loops" and bad battery performance?
> But it is, because the choices made in it were made for a different world of computing.
That's a very vague statement. What choices exactly?
Come on people, anyone can make these claims! This is almost the same as saying: "There is some software in Windows that is causing the bad battery performance." It's patently tautological!
The other guess is "there's some power-hungry components in Windows devices causing it!"
Yet the empirical evidence is that on the same hardware, with the same capacity to preserve battery, and on similar workloads, Windows yields a much worse battery life. Which has to come down to the operating system not sleeping when it should sleep, and doing more when it could do less. Anyone who has ever programmed ever knows that the primary cause of such work is polling.