There are too many lines of code to look for oddities... It's humanly impossible to study.

This is correct when there are massive updates that are backed up for over 18 months and pushed out by the devs as a blob. It is not the case when there are smaller targeted updates (such as the one release a few months ago to address some json spamming attack). The latter are more closely scrutinized by witnesses (not all of whom, but some of whom, have a software development background and are capable of reviewing code to a reasonable degree). Carefully reviewing and second guessing 18 months of design and development work that occurs largely behind a private and opaque process just isn't possible.

Either we flat out reject the release and insist that it be (re)packaged in small bite size pieces to be individually approved (and indeed a minority of witnesses is strongly in favor of this approach) or, absent some known, identified reasons to reject it (for example, stability considerations prompted by the recent crash was seen as such as reason by a minority of witnesses) or we pass it through on the basis of assuming that the dev team is competent. (If they are not, then the Steem community ought to be seriously working to replacing or restructuring it). All of which needs to be considered as a tradeoff between conservatism and 'best practices' on the one hand and the practical consideration of availability of upgraded features on the other (and numerous devs and community members were communicating to witnesses how important many of these upgrades were perceived to be, representing a clear incentive to get them rolled out).

Mostly, things are working now, and the upgrade glitches lasted about 1 day (exchange downtime is fully up to the exchanges, and nothing prevents them from being up; the necessary fixes was released to them yesterday). Whether getting the feature improvements out in deployment was the right call relative to stability risk will be something that time will tell.