As a fan of the "consistent environment" I am a firm believer in the value of a constant, scheduled update process, available via scheduled, and ad hoc delivery. We have had a few "issues" related to some updates, primarilly in older software, that is kept in production because of a business process, to "delicate" to bring up to current levels. In the relatively lengthy periiod of time I've been maintaining systems,

I think I have seen less than five significant issues, caused by a vendor supplied update. Our AV vendore delivered an update which not only broke AV, but made it impossible to repair without a local machine touch... (Tight looped to the point of useless...) ODBC updates were problematic for a period of time, but that was generally a mashup of different vendors supplying the same files... Internally I have seen issues with in house software, mostly related to a "siloed" test platform, where the "it worked on my machine" reasoning is applied. The Dev->Test->Stage->Prod model is obviously the safest, although in some ways brings its own challenges. Duplicating every system is obviously not a real option.

Our model is still update Test/Dev first, watch for fallout, and continue if no noise. The schedule helps us to anticipate issues, people may blame the updates for unexpected behaviour, but generally the update is not the root of the problem.