Atemu

Inconsistent time before sleep is likely the kernel waiting for IO to sync to disk.

Not going to sleep at all implies a serious issue that prevented the kernel from doing so. Check your logs!

Suspend reliability greatly depends on the firmware of your specific device as it controls the wakeup.

On my Framework 16 for instance, it is very reliable these days. I can’t remember the last time it woke up unexpectedly and I’m not sure whether it happened even once since the firmware update that fixed a major oversight in keyboard wakeup (waking when a key was pressed through a closed lid).

In Hyprland, how it works is that you define the screen lock command (e.g. swaylock) in hypridle and that gets wired into logind somehow such that you can loginctl lock-session.

I then (also in hypridle) define a before sleep hook that locks the session.

I believe the proper way to do this would be to run your lockscreen as a systemd unit that is WantedBy and Before suspend.target. This would in theory take care of making it idempotent and reliably show the lockscreen before initiating suspend.
A friend of mine has this sort of setup and, while it is reliable, the lockscreen is still racy and sometimes only triggers after suspend. Might be the lockscreen unit not signalling its readiness to systemd properly though.