It's funny that you say that, given that since S3 was effectively killed, I can't say I experienced proper sleep in Windows or macOS either. Linux so far is closest to my expectations.

My recent experience switching from Windows to Linux (NixOS) suggests otherwise.

I use a ThinkPad P1 Gen 3. My dGPU actually died due to overheating caused by Windows failing to sleep properly. On Windows, the fans were always noisy and temperatures stayed above 60°C.

Since switching to Linux, the fans are very quiet and temperatures sit between 40–50°C. What surprised me most is that sleep mode works much better on Linux than on Windows, where the frequent failures eventually killed my GPU.

Works fine for me, on Fruit Factory hardware even. Close the thing, it goes to sleep. Open it, it wakes up. Leave it closed for a very very long time and it hibernates. Open it again and it comes back to life. Your experience may vary depending on what hardware you run it on but for me it works fine on the mentioned machines, on a HP Spectre 360, another HP Elitebook and on a really ancient Toshiba Satellite. I've had problems with sleep on a Thinkpad P50 with a discrete NVidia Quattro GPU, it goes to sleep but won't wake up so I have that machine set to hibernate as soon as the lid is closed. This takes a bit longer (but not that long, SSD is fast) but it would have been more pleasant to use if normal sleep worked as intended.

If your computer fails to sleep, or fails to wake up correctly after sleeping, when running Linux then the problem is almost always the hardware manufacturer’s fault. Many motherboards come with frankly broken ACPI tables that should never have made it out of QA. Remember this (<https://news.ycombinator.com/item?id=45271484>) recent story? This is just the tip of the iceberg. For every well–researched story we have about ACPI problems there are a dozen more that are quietly fixed by Linux kernel developers (who instruct the kernel to simply ignore the broken ACPI tables and write a custom kernel driver to do the work instead) and an unknown but presumably large number that never come to the attention of a kernel developer.