This is the description of Android multitasking, but it's just as applicable as a description of iOS multitasking.
You can't really talk about the benefits of Android multitasking over iOS multitasking when you're describing the same thing.
I may be mistaken, and if so please show me where I'm wrong.
An Android application is composed of any number of Service components (0 or more) and an Activity (I think this is optional, so a package can provide services to third-party applications, see Bound Services[0]).
The Android "Activity" is what corresponds to an iOS Application: it's stuff with an UI which the user can interact with. An activity can not "act" in the background, if it's not visible it's frozen or dead.
A service, on the other hand, is headless (it has no UI). As a result, it has no concept of "foreground" and "background", if it's been launched it runs until it's been killed. I believe services also have little to no restrictions.
In Android, background activity (for applications needing those) is generally implemented via a dedicated service. These services can do whatever they want, which is a strict superset of Apple's limited set of backgrounding APIs. A drawback is that, because services can implement arbitrary behavior, it's harder for the OS to optimize them and it leaves them more open to abuse or coding errors than iOS's (or WP7's) more limited multitasking provision.
tl;dr: Android offers pretty much full multitasking, iOS only offers a limited, Apple-defined subset of it unless you jailbreak.
[0] http://developer.android.com/guide/topics/fundamentals/bound...
Emphasis on "recommended"...
Anyway there are a lot of technical things to say about the Android Multitasking System. Of course, there is the whole application lifecycle thing that the article mentions, and the Service object that others mentioned, but then again your intuition is spot on: it's roughly the same mechanism on iOS and Android. The key difference for Android is that it's the exact same mechanism that is used to navigate between screens of an app and to navigate from one app to the other, and this mechanism is the Intent system. Its main problem is that it's apparently hard to vulgarize it for marketing people.
Let's look at it that way: I tell the phone "show my inbox", the phone looks up a list of apps that declared that they can "show" an "inbox", and checks if they have access to "my" inbox. Once it resolved a list of eligible applications, it executes it using the Intent as unique call parameter. If the executable is a Service, it starts code in the background. If the executable is an Activity, it brings its Screen to the front and updates its content using the Intent's parameters. In our case, it shows the inbox of the user. If the Activity was still in memory, it doesn't create a new one but rather reuses the same and just updates the content. This is essentially the system that allows the "Back" button to work seamlessly, since the history is nothing but a stack of Intent objects, each with enough information to recreate the whole screen from scratch, or just update the content back to what it was before.
The AlarmManager system I mentioned above works the same way: when you register an alarm, you put an Intent in front of a Date. When the Date comes, the Intent is fired, the OS resolves the corresponding Application, Activity or Service and starts it.
In the end, Multitasking in iOs is exactly the same as multitasking in Android, but with an added regulation on what can stay really alive and for how long - the main difference is that the whole Android OS is designed on top of a system that allows launch arguments and contexts to be stored and passed around seamlessly at high speed. The result is why the article author said "multitasks like a boss".
For the end user, the only visible difference is that Android has a Back button. Oh, and that his battery life is in the hands of app developers rather than Apple.