The ghastly Helios accident [1] was also triggered by a misconfiguration (by maintenance staff). Sure, you’ll tell the pilots again to actually run their checklists, but you’ll also tell the maintenance crew not to screw up the standard settings.
Counterpoint: if you have a checklist item, and it is always in the desired/expected configuration already, you might start to skip it (with the concomitant consequences if one day it isn’t).
Maybe flight crews/maintenance staff should configure the machine randomly after a flight/maintenance, so as to force the next crew to actually run the checklist carefully?
Would you manually reinstall and reconfigure your workstation every morning?
Some settings should clearly start as blank and be required. Other settings could start as as a default value (defined by the airline) and the pilots would merely have to confirm that it is correct, or deviate from it.
The point is, we can do a lot better UI-wise than just reusing the settings from the previous flight, and with a little thought put into it the configuration process could be both safer and faster.
This reminds me a little of Adam Langley's advice for keeping software protocol extensibility points well-oiled:
You might want to define and implement dummy extensions once a year or such, and retire old ones on a similar schedule. When extensions contain lists of values, define a range of values that clients insert at random. (https://www.imperialviolet.org/2016/05/16/agility.html)