Examples of Hal not letting a pilot save the day?
I agree with the opinion that people would rather tilt the scale in the direction of allowing a pilot to screw it up vs. allowing the system to end the day by not permiting the crew to take over. I would like to know about examples of when the pilot's inability to take over has been a major contributor to an accident - I can't think of any right off hand.
I think the bigger problem is that crews have all too often lost situational awareness and have either blindly followed errant displays or simply persisted with pilot inputs that were not appropriate (e.g., nose up command when at high AOA and descending due to stall or simply insufficient lift resulting from very low speed). I would put erroneous air data high on that list. The air data technology we have on commercial transports today is not sufficient to ignor the need to recognize when it has failed and to respond accordingly. Both Hal and the carbon units up front have a role to play in this one.
Another issue is pilots being unfamiliar with flying without the autopilot and/or autothrottle. Closely coupled is lack of awareness of the current automation mode(s) and thus not recognizing what pilot inputs are needed to fly the intended path/speed. The B777 clipping the seawall on the way into SFO is a prime example of the crew not recognizing the need to monitor and control speed. For that event it seems that the crew may have assumed that the autothrottle was minding speed while they made an attempt (all be in not a very good one) to manually control path.
I would sure be a supporter of simulator training where starting at cruise an engine is failed and both the autopilot and authrottle are disengaged and the crew has the task of landing at an alternate. As SLF I would be more comfortable in back if I knew that the team up front had that practice on a regular basis.