The situation is not as simple as the above arguments may lead someone to believe.
As far as CPU power consumption is concerned, keep in mind the CPU is always running, even if idle. In an idle state it just executes a loop, waiting for the next event to happen. The power to the CPU is not turned off unless the machine is in a SLEEP mode. The ideal system is a CPU that is entirely interrupt driven, switching completely off when not in need, but I do not know of such a CPU. It needs to be clocked and driven with power in order to monitor interrupts coming from the keyboard, screen, network interface, timers, software etc. An application that does not require CPU attention does therefore NOT necessarily consume extra power. The first misconception therefore is that more software in memory uses more CPU power.
One needs to distinguish between memory space usage and memory access. In an oversimplified way one may say that the former does not require additional battery power, while the latter does. Memory space usage cannot affect power consumption since whatever the information written into memory does not mean the machine is actually accessing that information. If a task is inactive (maybe because the front end of a Notepad application has been minimised or closed down) there may be a significant amount of code and data stored in memory, but if the NotePad does not actively access that information, then it lies essentially dormant. Therefore the number of apps in memory CANNOT affect battery power by itself, since the information in memory does not use battery power by itself. Memory chips require a fixed amount of electricity to hold information, even if the information is junk. The amount of electricity needed scales directly with the total amount of memory in the system. If your Android system has 8 Gbytes of RAM, then the memory uses the same amount of electricity, whether the 8Gb is full of junk or filled with software. This is especially true for dynamic memory which is the typical fast-access memory used in computers and hand-held devices. The second misconception therefore is that more software in memory uses more electricity.
Having said that, there are three exceptions to these two basic statements:
1) When memory is being accessed. Reading information from memory requires additional electricity because of the additional circuitry that needs to be activated to do this. If a background application accesses memory all the time, then it actually consumes electricity, even though it is running in the backgound. However, an app should NOT access memory if it has been relegated to the background because it is not required any more. Memory chips heat because of CPU accesses to that RAM, not because the RAM stores information.
2) Background processes can monitor external devices such as the Internet link. For instance, if GMail is constantly checking for incoming email, then it accesses the Internet hardware, writes some of the results to memory, and continues to perform duties even while GMail is only running in the background. This uses up electricity.
3) Some software, e.g. a Bluetooth interface, uses physical hardware that is "normally" not switched on. The user needs to switch it on or off, therefore the onscreen tools provided by Android to do exactly that. Software in the background that used WiFi, Bluetooth, GPS (e.g. geotagging of photographs) therefore can use a considerable amount of electricity if this ancillary hardware is used and the results written to memory. Background apps that use these hardware therefore use electricity.
The above I hope shows that background tasks can (and do) often use additional electricity, even if they are only running in the background, supposedly in an "inactive" state. In order to conserve battery power, kill all software that makes use of the LAN/Internet interface, the GPS facility and any hardware that is not needed at a particular moment. Software that writes to memory (or to disk) on a regular basis should also be killed if their services are not required.
Given the superlative design behind the Unix/Linux OS in terms of efficient multitasking and the handling of of background processes, we might expect that the management of power may be close to optimised. However, if one runs a geotagging process as part of a camera that is running in the background, then we cannot blame the OS for consuming more battery power because of GPS accesses. The user did not kill the camera software and the OS thinks the user still needs the geotagging facilities.
To sum up, it is good to know which applications use battery power. Android provides excellent monitoring facilities to see which apps are the culprits. I would use software such as ATK to see that these pieces of software are killed when not required, afterwards killing ATK itself as well. I hope this offers some extra perspectives and a compromise position between the above two extreme positions.