"What's wrong with their current multitasking solution?"
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.
1) no battery will be consumed by "runaway loops" because it will either be closed or be completely frozen in the background, regardless of the app design and epoch (pre- or post-multitasking)
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...).
Which ones? I'm curious, it would be interesting to know about them so as to avoid such buggy bastards who dare to resist to SIGSTOP (or its equivalent).
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.
(2) You shouldn't have to manage them manually. Also, but orthogonal to that is that the multitask bar blows from a user experience point of view. (Just by way of example, if you do decide that the user should manage memory manually, you should at the very least provide some kind of indication about how much memory/threads/resources each app is currently using, otherwise the user is just shooting blanks in the dark (sic)). You didn't previously (need to do this) under single tasking. For most apps therefore single tasking provided a superior user experience.
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.
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