GNU's procps/top is an incredibly full-featured, indespensible system monitoring package in the Linux world.
One of the capabilities of top is to send a signal to a process. Send signal 1 and, if the program was written to cooperate, it will re-initialize itself. Send signal 15 and you're asking an app to clean-up and exit. Signal 9 is intercepted by the kernel and a process exit is "forced."
All of those task list/manage/kill apps are derivitive of that original top application.
Stopping a process (signal 15) is usually harmless, at worst leaving behind temporary files or failing to save its persistent state/configuration. But forcing a process to close (signal 9) should be a last resort, used only after you're certain that waiting is hopeless. It usually just "kills" the process with no ill-effects, but sometimes it will create a "zombie" which can make it impossible to fully restart the app until the OS is restarted.
A zombie's inablility to die may impede an app's ability to restart, properly control itself or communicate with its sister processes. More commonly the process header, the IO data structures, device hardware and/or interprocess communication "protocols" can become deadlocked, wasting system resources (kernel data structures, memory, VM). In some cases this "corruption" can result in runaway processes or an anomolous SW/HW state that could drain the battery at an accellerated rate. In all cases these problems can be cleaned-up by a reboot.
How can you tell in task manager which apps are sucking cpu?
Android Market has a free application named "top" that was no-doubt inspired by its big brother. It though is a simple process list sorted by the CPU% column. Its other columns may give you a hint at the resources allocated to the dormant processes no longer being used. Those resources are saving the exact state of the application. It makes the app available more quickly as it's already initialized/running.
SO a dormant process is not using CPU time, and the fact that it is using memory (real or virtual) is not a hinderance to overall performance because the kernel and its system processes know how to reduce most of the footprint of the dormant processes when resources run short.
So if the OS can reduce the real-memory footprint of dormant apps, what's the benefit to killing them? Just as the amount of RAM (real-memory) on the device is finite, so too is the swap file space (virtual-memory) and kernel data structures (process slots, open files, IO buffers). If your swap file is full you would get an "out of memory" message and applications will fail or refuse to start. Also, anytime any of the system resources is nearly exhausted the allocation of that resource is slower and will kick-in "garbage colection" routines more often.
But still the user does not need to kill the process. The Android OS will kill the older, dormant processes as necessary to recover system resources as needed.
Normally in Linux, if you get "out of memory" failures you may want to kill some processes. In Android we should not get "out of memory." If you do, the "Home" or the OS "ROM" is buggy. If you get "out of memory" or "Force close" prompts or recognize a pattern of poor performance, you may be able to figure out an app to avoid. And then there's always my favorite system management saw, "when in doubt reboot."
BTW, Windows does this all virtually identically to Linux. Android though has some additional magic to remember the state of an application so it may be restarted right where it was in case it needed to be stopped to reclaim resources to allow another app to run.