This is an interesting topic, and I'd be curious to have a few questions answered for our design and development team. Trying to move away from the specific language of BigFix/IEM, it sounds like there are two issues here.
First is the ease of creating a patching policy that can be leveraged from within BigFix. This "policy" might be "all critical or important Microsoft patches should be remediated" (and it sounds like Tim can quickly create this) or "all Microsoft Recommended updates" (which Blake finds more difficult- I'd be interested in getting more detail here). I know some customers only include patches they know are currently applicable to some machines. Is this just to reduce the size of baselines, or is there some functional reason?
The second issue seems to be how to deploy the patches. Some products have a set it and forget it approach: define the policy, and tell all your computers to follow it. As Tim and jgstew point out, this can make you a bit exposed to bad patches. A couple related questions:
1) How many of you would leverage the "set it and forget it" approach, and what kind of progress tracking would you be looking for there (e.g. just call out failures, or maintain the current level of detail on all patch deployments)?
2) Would a simplified version of jgstew's approach work? Create a policy, apply it to all machines on a regular schedule (e.g. 3rd week of the month) but schedule test groups to run it first, and enable it to be canceled if error reports come in.