So if your kernel woke up (let’s say after 30 min of suspend to ram) to try and see if it can reclaim physical DIMMs and mark them unused (shrink caches, reorganize pages, etc) you could get quite a big win on standby time. The trick is how to do this without actually hurting battery life (waking up can be expensive and there’s no guarantee you’ll be able to free up DIMMs) and preserving wake from suspend performance (if you’re phone is laggy on wake that’s an experience users will switch away from + you could eat your entire power savings paging back in).
And, I am referring to active idle, not suspend-to-ram scenarios. I think people are talking about screen-on time for battery life, not lid closed and suspended nor lid open but screen disabled. Precious few people are enjoying a laptop that successfully performs a suspend to RAM sleep state while keeping the display alive. Often, the integrated GPU is continuously scanning framebuffers in system RAM and outputting pixel data to the embedded display port even though nothing is changing on screen. Frequently, drivers have disabled LCD panel self refresh modes due to unresolved glitches and artifacts in the graphics stack.
But, the largest differences are probably in idle power management, with the phone having much lower power IO channels and better zoned power management to really reduce idle power. A laptop often has the system in a much higher power level with off-chip resources powered up, including WiFi, screen refresh, data buses, and backlight driving a much larger screen area.
Edit to add: I've noticed on laptops with Linux that vastly different battery life from "similar" machines come from differences in how the software and firmware interact to reach different powersaving modes for screen on but idle states, such as with a browser open on a page that has already rendered and awaits user input.