There are a number of pretty severe problems with that article.
1. 'The designers intentionally left out a task killer and ways to close apps.'
Actually, no they didn't. The operating system is Linux, with a Dalvik virtual machine (like Java) running on top of it. Linux most certainly does have the means of killing tasks (signal and interrupt handlers, and the userspace "kill" command), and indeed this is something highly fundamental to the OS. There isn't a "convenient" GUI provided by Google for the "kill" command, but IMHO that was a mistake, based on their rather over-optimistic faith in (the present version of) Android's resource management.
2. 'Google did not want to burden the mobile user with having to close applications when they are "done" with them. They decided to do this on the basis that a mobile user will repeatedly and briefly interact with a wide variety of applications throughout the day.'
That's quite an assumption, not necessarily consistent with user habits, and not any sort of justification for hogging system resources unnecessarily - even if it is.
3. 'I know that this stands true for me, as it will 99.9%'
That's a highly arbitrary and speculative statistic.
My usage habits are very different. I typically use the Groundhog newsreader once a day, then close it. I use "Guardian Anywhere" first thing in the morning, then close it. I leave K-9 Email running all the time, because I like to be notified as soon as I receive a message. I use things like the camera only very occasionally. I have precisely two games (Asphalt 5 and Assassin's Creed) which I hardly ever play at all. I have some music and videos on the phone, but I don't use them every day. Mostly I just use my Android as a phone, for Email, and as a GPS.
In total I have about 30 third-party applications installed. Something tells me the ~330MB of available memory on the phone would quickly be exhausted if I attempted to leave all that running, even with Android's inbuilt resource management.
4. 'just because a process exists, does not mean it may be actually; doing anything'
It's just as imprudent to assume a task is not doing anything, and indeed it may switch from being idle given some change in its condition (schedule). In addition to being a resource hog, unnecessary tasks present a security risk (an attack vector that would not otherwise be available). There are also certain tasks that might be prudent to disable, depending upon location (e.g. GPS tracking), perhaps for reasons of privacy.
5. 'running in the background (true multitasking)'
Running in the background is called forking, and although dependant on multitasking, is not synonymous with it. The term "true multitasking" was coined years ago to differentiate between cooperative and pre-emptive methods, however both methods allowed services to "run in the background". The first uses interrupts to suspend tasks, and the second uses scheduling to assign quantum slices, but this is non sequitur to the process of forking.
6. 'Storing a footprint of an application in memory uses exactly the same amount of battery as it would if that section of memory is free.'
This is another non sequitur argument, because memory utilisation is not the point. The point is potential CPU utilisation by tasks which may or may not be idle. This is where the previous point is important, since a task is not necessarily idle simply because it has been forked ("running in the background"). Higher CPU utilisation most certainly will drain the battery faster.
7. 'Android is smart enough to recognise when it is running low on available memory, and will start to close those apps that it deems are low priority.'
This is true, although the default algorithm Android uses to determine when to close applications is not particularly effective, often resulting in slow performance due to a near exhausted resource condition. This can be changed with third-party applications like "Autokiller" and "MinFreeManager", however it would simply make more sense for the user to close applications after using them, given that they may not be using them again soon, and that launch times for most applications are typically only one or two seconds anyway.
8. 'When android does close apps itself to free up memory, it does this in a very clever way in that the next time a closed app is reopened, it will restore it as if it had never been closed in the first place (this is similar to what iOS actually calls it';s main multitasking, laughable I know).'
Not defending the iPhone, however this "laughable" method is what I referred to before, a form of cooperative multitasking where tasks are temporarily suspended. And yes it is inferior to pre-emptive multitasking, however this appears to be the method Android uses to avoid memory exhaustion. The only real advantage to this compared to killing the application fully, is that it'll be restored to its previous state when re-launched, but there are very few applications which require this (document editors come to mind). Personally, I'd rather just save the document and close the application.
9. '"Task killers make my phone run faster" - FALSE'
Not true.
Whilst killing a necessary task may cause it to be respawned, thus temporarily slowing the system down as it re-allocates resources, tasks left running for a long time may allocate far too much resources (cache, etc) and benefit from a "fresh start". This is about far more than just memory leaks. And that's before one even considers the reduced CPU utilisation attained by killing unnecessary tasks.
While it is true that killing a task won't necessarily improve performance, it's equally true that it might, depending upon the circumstances, and in the long term (after resource reallocation) it certainly won't do any harm ... unless a process gets stuck in a loop tying (and failing) to respawn, at which point the parent task will also need to be killed (the "tree" of tasks is displayed using the command "ps auxf" with ADB or a third-party terminal program, and this will show which task is the "parent" of which "child").
10. 'There is no exit button because android was designed to never have the need for a user to close apps. If an app needs closing, android will do this itself.'
That is Android's intended goal. However, with version 2.1 (at least), it's a goal it largely fails to achieve with any great success, thus necessitating the use of third-party applications. Version 2.2 is likely to show a large improvement (my phone should get this soon), but that shouldn't mean users become complacent about leaving applications running, on this or any platform, for many reasons, of which resource management is only one.