The part about not being able to run anything when you aren't the active program is more limiting. Clearly it is possible, mail gets received even when mail isn't the program, but that is Apple. I can see their point in restricting it, a single lazy coder can degrade the entire user experience and run down the batteries, but there is a class of programs that can't be built in this model.
If I want to write a system monitoring application to keep track of my important machines, that is easy and I can be very slick. But what if I want to be notified when there is an anomalous condition back at the server farm? If my app is running I can hold a connection and monitor it for incoming alerts, but if I'm not the running application I'm completely out of luck. I suppose the server side code could send me an email telling me to run the client, but that is a sad sad way of living.
I expect they will address this in the future. I can think of a couple ways...
1) Add a program to the sandbox that runs at startup but with brutal resource limits. Implement just the bare necessities of listening as efficiently as possible.
2) Make a remote notification manager of some sort. The server can make a remote call, the app runs a call handler briefly and then exits.
3) Do a cron-like operation where it looks at a crontab-like structure in the app's directory. Again, enforce brutal resource limits to keep lazy programmers from ruining the user experience.
All of these also have the problem of how to speak to the user during another program's session. A pop-up box is probably doable, you see those for carrier issues when away from AT&T and they work ok. The ability to play an audio message would be nice, especially if it ducked any existing audio.