bah, today's experiment failed miserably. Evdev touch stuck on 100% processor usage eating up all my battery. I'll try again tomorrow

Similar here. Early option seemed as battery efficient as suspend enabled, connected ok after 1h (1% battery drain in that time), after 4h too although had a strange behaviour in mc (2 seconds responsive, then ~5 seconds unresponsive, back and forth, mostly visible while scrolling in big directories), extra 2% battery rundown by this time. In the morning couldn't connect. After waking the device up it showed ~70%, not sure how but 20 minutes later checking emails/web browsing it was already down to 30%, evdev touch, msyncd and timed-qt5 in htop seem to have spikes in activity going 100% on both processors (actually over 100%/200% if you count all percentages of the processes, bug in htop?), don't remember such behaviour previously, could be related to the battery rundown. Needs more testing

early suspend policy seems viable. After around 14h of my regular use I'm still at 55% which is pretty good

I have had good experiences for ssh responsivines by changing the sshd clientalive -parameters.

in /etc/ssh/sshd_config i uncommented following parameters, and changed interval to 15 secs.

ClientAliveInterval 15
ClientAliveCountMax 3

(This helps only when ssh opened to the phone, but it seems to keep e.g. all qml timers running)

Do you mean when using a ssh _client_ on the phone?

Otherwise it would be weird -- because by changing ClientAliveInterval on the phone it is actually the phone the one that should be sending ClientAlive messages. But the phone is suspended! So it would do nothing at best and at worst it would cause the phone to drop the connection when it awakens....

Note that changing mcetool settings survive a reboot (wakelocks do not).

I remember reading this back when the n9 came out and sending it to my android-loving friend to show him how google's heavy-handed approach to power management isn't the only way. It's a bit disappointing to see that Sailfish is so androidy on the sbj. Does that mean it's basically an android kernel?

Yes, that's the case. At least, from init onwards it is more or less a GNU system (systemd based...) albeit with an Android chroot where the Qualcomm binaries are run.
Which is different from the Aliendalvik one. Effectively, the Jolla device contains two separate Android userspaces plus a glibc one .

By the way, I've not been able to reproduce that issue, either with wakelocks or by using mcetool. I am now using the mcetool 'early' setting and have had no "runaway" processes so far.

Battery life is bad (~1 day with light usage) albeit it is also similarly bad with stock settings (I assume tohd bug, but I'm not certain...). I still have no SIM card inserted.

that issue is completely unrelated, I didn't mean to present it as a sideffect. It had happened to me once again days before I started playing with standbydedness.

BTW battery life is not bad here, sim inserted, 3G always on, gtalk connected, light usage (most of the day near wifi, one or two short calls, around 15 minutes of 3G browsing, no wifi browsing today), suspend-policy early and after 12h I'm still at 68%

Battery may get better if these 'optimizations' for the Qualcomm SoC that were mentioned before the tohd fix come about. If it gets up to n9 levels with early-suspend, I can see a lot of people switching.
Totally loving everything being Qualcomm's fault, by the way.