A well-written application will either do the work it needs to do or wait at a blocking syscall. This means that as long as all of the applications I'm using are well-written, I don't need to suspend the applications.
A diagnostic tool to find out which applications are battery-hogs plus the possibility to force-suspend the misbehaving ones (as an opt-in; Android Doze is an per-app opt-out which is one of the reasons it's so horrible)
Agreed. Then, if the application will tolerate a ~5 seconds deviation from the sleep time, it should declare it. The system should not break the applications.
... The whole idea is, that just as I am the only lord, master and the emperor on my Arch laptop, I expect the same on a phone. 1. On my Linux box an app will (almost) never be killed unless the situation is critical. Usually, if I run out of RAM (i.e. all the buffers get cleared) the system goes so unresponsive that I use the magic sysrq to kill the memory hog. I expect the same on a phone: no app killing, unless I approve.
2. On my Linux box, an app will not be suspended without my consent. If I'm compiling the kernel and turn off the screen, the device will not stop compiling the kernel because the system is too intelligent. I expect the same on a phone.
3. The real problem comes when you decide to port a desktop app onto a phone. A correct app will suddenly stop working because the operating system is too intelligent, even if it does nothing wrong.