I know this isn't related to the argument but I thought it worth posting.

I'm not sure what you mean by 'downplay', but Android uses explicit events to separate process-level multi-tasking concerns and gives the OS the ability to choose what to do with the process once backgrounded based on its configuration. This is certainly more complicated than the brute-force approach to simply having the kernel handle task scheduling treating all processes as more-or-less equal and in no way 'downplays' it. It also gives developers explicit control over what parts (if any) are put to sleep when the app loses focus and allows them to run their own code during these events. This is a boon to battery life and performance; upon losing focus, only key code can remain running in the background while other code is shut down. Consider how long our laptops would run if such event separation were included in applications from the get-go!

<offtopic>
But arguably the largest benefit of such a system is not having to explicitly close applications (well, the ones that are coded properly anyway) -- one of the great features of palmOS of old. When the OS needs resources, it can dump idle processes and state save. For apps that are intended to be backgrounded, the developers simply need structure the application accordingly and the app will continue running in the background.

But the problem is as you say: many developers (including google's own) seem not to use the facilities properly leading to bad resource utilization and the need for task killers. It seems, as always, the additional layer of complexity introduces the chance to err at an increasing rate.
</offtopic>