If everyone codes their apps perfectly, nothing.
On the other hand, if there just happen to be one or two cough apps out there that are coded according to the pre-multitasking way of doing things there are three main problems:
(1) it will consume more battery, because the apps will pound away in their inner loops blissfully unaware (because they're not listening, or didn't handle it correctly).
(2) it removes control from the user, since a mostly crashed app will remain mostly crashed. Under the old scheme you could exit out and then go straight back in, in order to start with a 'clean slate' (sic).
(3) it uses more memory, on devices that are painfully low on memory. Half a gig (actually less for overhead) was okay-ish when you were the only thing running... but when it is being shared it doesn't go very far at all.
(4) off by one errors
To perform computations in the background, an iOS app has to be voluntarily coded to do so by using the multitasking API.
(3) half a gig on the iP4 is plenty enough to hold numerous Safari tabs, a huge game like Infinity Blade or Dead Space, and half a dozen random apps (twitter, messages, mail...).
Half a dozen apps is not very many apps. In fact, it is a ridiculously small number of apps for a device that is "all about the apps".
The task switcher is not a task bar, it's a MRU list. You're better off finding them again on Springboard if they're not in the half-dozen most recent apps range, which is muscle-memory. What do you expect? you can only fit so much on a ~3" screen and make items touchable. Stuffing more icons would make the task switcher end up looking like Springboard anyway, only messy because you'd have to scan through it due to the number of items. Springboard + muscle-memory beats that anytime.
3) iOS will shut down LRU'd apps as it runs out of memory. This is a non-issue.
Most of the issues for me around multitasking center around the UI.
The obvious exception is apps that do some kind of notification, e.g. if you wanted to write your own SMS or twitter style client. Given the vast numbers of apps coded for the single tasking paradigm, it would have been better to create some kind of 'opt-in' notification API (a good one, not whatever they had previously).
(3) to an experienced eye the performance degrades as it reaches those limits and starts having to do app level garbage collection. Also, this means that apps need to pay more attention to their own memory management and the low-memory messages they are receiving from the OS. In a perfect world this would have already happened. Given the ... how shall I put it ... journeyman level of experience of most iOS developers this is an utterly unrealistic expectation. This is a big issue.
But the app switch interface in iOS is less than desirable, it'll quickly clutter up even if you do not feel the lag, you'd wanna X everything off just so you don't have to scroll to the left 6 times to reach the app you intended for.
What I meant by my original comment is that for me it doesn't work as I'd like. It may be an issue with the apps I use or iOS's way of doing multi-tasking.
I listen to 5by5 podcasts (atomic web browser) and follow the discussions on irc (Colloquy for iPad).
I someone posts a link on the irc and I follow it when I come back to colloquy I don't get any of the messages sent while I wasn't looking...
When I use the AndChat in my Nexus One I can happily go watch a lolcat and when I get back I can read all of the I can haz messages everyone sent while I was looking at the site.
That use case is the one I consider broken in iOS, maybe Apple doesn't care about people who still use irc or maybe it's Colloquy that's broken.
http://www.pcworld.com/article/199891/geek_101_android_and_i...
http://www.pcworld.com/article/199830/apple_ios_4_vs_android...
On my iPhone 4 and iPad, I can switch back and forth between my frequently used apps (NetNewsWire, Instapaper, GoodReader, Evernote, Omnifocus, Elements) and they rarely have to relaunch. When I return to an app, everything is how I left it.