Applying the patch a few days later typically doesn't noticeably increase your risks but rolling them out unchecked can make some serious damage.
Before, many enterprises rarely patched because the testing involved was a huge pain and it fell outside what they typically planned for.
If you don't want to apply the patches as soon as they're released, then you'd be more than welcome to put them on hold for 4 weeks yourself when it's more convenient.
Your options become either to release an update the moment it's tested, immediately making vulnerable customers who have a change management policy (usually also the biggest and juiciest targets - fortune 500s including ironically the likes of Google), or delay any release until some coordinated date, giving everyone an equal and predictable opportunity to cope with the exposure, which is how Microsoft do it.
What are the chances that attackers or other agencies already know of these vulnerabilities and are exploiting them?
Microsoft's delays extend the time that the silent attackers have.
There are bad guys looking for 0-days out there. If they learn about the vulnerability from the patch, at least the world has the patch before the bad guys do. Now it's the opposite.
Edit: See _wmd's explanation about the technical details of all this in the same level of the answers.
You apply a dozen different fixes and test. Something breaks badly. You now have a dozen different root causes to check when, if you applied one at a time and tested (or applied one at a time and let your users test it, which is more commonplace than it should - automated testing tools exist for a reason) you'd know what broke.
I'd prefer to have fixes available for rollout as soon as possible and to decide whether I deploy them or not based on my tests. Automatic mandatory deployment could be on a fixed schedule, for those who can't test or don't care much about it.
Releasing the patch late (i.e., on patch day) makes that choice for everyone.
It's not that just the big companies are affected now: all users are.
Large enterprises already have centralized patch management, so they can decide how fast it gets pushed downstream to their users after MS releases the patch.
I haven't come across a source for that. Does one exist?
For all I know, Microsoft announced it in reaction to the publication, but I have no clue Google could have been made aware of it beforehand.
Edit: nevermind, I've found one.
You are new to IT aren't you?
Failure to blindly adhere to the common view isn't the same as being new.
Which is a dumb policy for security patches. When its fixed it should be released.
> If Google isn't willing to wait the two additional days such that the patch can be deployed within the regular update window, this means that Google effectively gives MS only 60 days to react and fix issues (because once they missed the second patch day, the vulnerability will be disclosed before the third).
Google doesn't dictate Microsoft's patch releasing policy. 90 days are 90 days. Microsoft doesn't have "only 60 days", they have 90 days like anyone else, and they chose to miss it by adhering to a policy of their own choosing that makes security patches less timely.
The whole purpose of a fixed 90-day window is to give reasonable time to fix a security vulnerability but also to create pressure to do so timely. Making exceptions for vendors to accommodate existing policies that make security fixes less timely would both increase the effort for Google (as a fixed time window is always easier to implement than one that varies with each vendors policies) and undermine the whole purpose of the 90-day timeline.