I think the real question is over how constraints should be exposed. I'm very much on the side of inferring constraints from the behaviour of userland - if they have a device open then we should assume that they want to use it, so should avoid shutting it down. We're nowhere near providing that level of functionality in the kernel yet, but doing so helps the embedded, desktop and server worlds.
I'm not sold on the idea of providing explicit constraints in most cases. If you're going to provide that constraint explicitly, why not allow the kernel to infer it? The code to say "Nothing needs access to input devices now" is not significantly differently complicated to the code that closes the input device when it doesn't need it. But that's the kind of case that the Android code deals with now.
Stuff like the pm_qos framework deals with a different case, where you're supplying additional functional constraints to the kernel above and beyond those that can be inferred. I think we should be focusing on what those constraints might be rather than thinking about the wakelock and early suspend code from Android.