Background vs running in the...
It's one thing to let an app go to the background and come back. Letting it DO things while in the background is a completely different story.
If you're using an app on a phone when a call comes in, it pauses processing, you take a call, then it returns from a cached state to the foreground. This is acceptable. It's like hibernate. Not in the foreground, no CPU access time.
For remote support, if the phone is operational enough to connect to the wifi or cell network, why would it be so hard for a user to launch the forground application? The only thing a remote support agent would need access to on an iPhone would be the settings files, and those are not exactly located in a file system for easy access. The phones are programmed by connecting via iTunes. There are no AT&T specific apps on the phone to support. AT&T doesn't even support the phone, only Apple's own people do, so why do we need a 3rd party app for this again? If the phone is locked up, you need a PC to fix it, and remote support is useless anyway. If it crashes, it reboots. All we need is a log file to be able to send to Apple support from within the phone's interface as an e-mail attachment... There's not much for them to do other than identify who's 3rd party app (or their own) crashed your phone.
As far as chat... um, we have SMS and e-mail and they both run in the background, sort of... The program itself doesn't need to run there, just the transport layer (protocol), for which Apple could easily add a simple chat protocol the the OS that's allways running if configured. the phone itself does the background processing and alerts an application. mail doesn't actually RUN until you launch it. Only the Apple OS tells you you have an e-mail... why can't this be done for chat? it's just another protocol... Chat won't be using resources in the background. What good is presence awareness when you're not looking at the screen anyway, right? All you need is notification someone's trying to chat you. You turn on the phone, see a nuber on the chat icon indicating you have a message, then open the app to get it which is when the message actually downloads...
On the central chat server, the chat program can know wether the app is foreground or sleeping, and if someone sends you a chat, the central server does presence awareness and sends a message, (at your option) to either your e-mail or SMS to let you know someone is trying to chat with you if there's not some inherent transport layer Apple can provide... This will require client side or server side support for anyone wanting to chat with an iPhone, but this is not difficult.
I don't want apps using up background resources on my phone. I don't want the CPU and battery being tasked if I'm not actively using a specific program. I don't want some app hitting the net every 10 seconds forcing edge or 3G to broadcast continually. I don't want a choppy call or jitter in a movie because some app is hitting the CPU to hard. The OS layer, provided exclusively by apple, should have a list of protocols that IT and only IT can run continually. If an app is configured as the default app to talk with one of those protocols, and there's activity, than Apple can update their Icon on the screen and chime you.
With what's going on in the phone industry, free unlimited everything plans and all, I doubt AT&T users will have to wait too long until SMS is 100 % free all the time. presence awareness is a bit more difficult, and would need to be server side (or controlled by the remote client) but again, to restate, I don't want some friend or family member causing my battery to get eaten up because they feel they need to keep me in their chat window all day long and know exactly when I'm in range of a signal or not.
Apple's idea of refusing background apps makes the device more stable, the OS response more predictable, and makes it impossible for there to be a virus, or for one program to damage another one's functionality. It's a stance MANY other phone makers should also have.
I think the ONLY room for wiggle here would be it the phone is on, and logged in (not sleeping) and then maybe Apple could allow certain applications to run in a quasi-background mode, provided a call is not in process or a video is not active (or limit CPU cycles or something to ensure non-interference, though fron what I understand, the iPhone OS is not actually multithreaded yet).