_User_ triggered apps/windows/dialogs are allowed to take focus, because it's clearly the user's intention to open/use that app. This does not hold true for automatic updater windows, such as update boxes, new chat messages, etc.
OS X for example gets this half right, with the play sound and bounce dock icon features. The perpetually bouncing icons can drive me crazy, so the best solution would be if cmd-tab automatically put apps demanding user attention first in the open apps list, so that as soon as there's a dock bounce, I can get to it with one quick cmd-tab. That way I can get to it fast and I don't run the risk of the spacebar-ok|cancel disaster (which in minor forms has happened to me before too).
You could probably take away the ability for an app to grab focus for itself (but an app with focus could assign focus) with no real loss - just mandate that the notification area be used instead. Of course, that's ignoring legacy apps, so it can't really be done (smoothly), but there probably is a clean, correct in hindsight solution to this problem.
Then again, if they're going to break stuff just because in Vista... might as well add something useful!
-------
Why can't I get Help from this program?
The Help for this program was created in Windows Help format, which was used in previous versions of Windows and it is not supported in Windows Vista.
For more information, see Windows Help program (WinHlp32.exe) is no longer included with Windows on the Microsoft support website.
The real solution is to have a coherent security policy in the OS. Then things won't get urgent for automatic updates. Beyond updates, there shouldn't be much need to ever have an app take focus after already running. A visual notification like those little hopping icons in OS X works very well.
Your point about an app taking focus makes sense. It's really a question of etiquette. A reasonable underlying system would allow apps to take focus, but it would less often be urgent and most likely in response to user input, not not interrupting.
Generally speaking, I agree there are a lot of complicated race conditions in GUIs. Parts of solutions: more global undos and event logs, disabling controls for the minimum human reaction time, less invasive dialogs and event notifications, faster feedback...
Usually these bugs are caused by someone fixing another bug. It seems even wronger when a dialog box or some other new window comes up, and the focus is not on it. This gets reported, and the programmer fixes the problem by taking focus.