S0 standby is the problem. It's a flawed idea from the start. The theory is it's more "secure" or something. But like... Who cares about stealing shit from memory going from sleep to wake.

Now my laptop drops 20% charge in 5-10 minutes and goes into hibernation. It draws more power than if it's on.

Newer Dells have removed the s3 deep sleep. I believe the cutoff is between Intel 11th gen and 12th gen in (at least) Latitudes. I have a i7 12th gen that sucks at sleep, but an i5 8th gen that sleeps well.

I think the laptop really does matter, and it's because chipsets are not all equal in how well their sleep modes are supported in the OS.

I've been buying XPS13s for over a decade; I've had four (three personal, and one requisitioned for me by my job), and sleep and suspend have worked almost flawlessly on them under Linux. In the office, most everyone else would move between meetings or to their desks with the lids almost closed, to prevent sleep and the problems it caused, but I'd just fearlessly close my lid; it was ironic to me that running Linux on the XPS I had more reliable sleep behavior than the Windows people on their laptops.

For OP: low power, initialization, and restoring state has to be implemented by each chip, and there are a lot of shitty, poorly implemented chips. Then the OS also has to store and restore state for each chipset, and even if the chip implements it well, the OS has to do a good job restoring power in the correct order and restoring the state for each chip. If anything goes wrong in either the chip or driver implementation, you get a broken state.

This is aggravated by the fact that Linux is a monolithic kernel, and if any device drivers get borked it usually borks the whole kernel. This wouldn't be as bad a problem if Linux were a microkernel architecture and drivers could just be killed and restarted.