There are a few useful properties with checklists:
- They stop you from having to improvise actions when time is too short for that. People under stress take bad decisions. It's better for them to stick to a pre-defined plan.
- They stop you from making preventable mistakes. People forget stuff. Even trained people. Especially routine stuff.
- They ensure some level of uniformity to people's actions. So, they can check each other's work and do some cross-checking.
For IT operations, run books are great. Especially if you can automate them. CI/CD is basically an automated run book. It simplifies the decision process for humans: do I want to put this live: yes/no?
But what do you do when the database goes down or there is some major hardware failure and you have to restore from a backup? In a lot of organizations, this is still a major crisis. There might be a run book but chances are nobody has practiced this in production in ages. Thinking through ahead of time what you would do is more than half of the success. It doesn't matter if it involves some manual steps as long as you know what they are. In aviation, a lot of stuff is not automated at all. And they still use run books and checklists. These are a great substitute for automation. Newer planes self-check a lot of stuff that you used to have to do manually.
Ideally you have both automation and run books. And automation can fail of course. What do you do when your cloudformation stack is corrupted or when your terraform is out of sync with what remains of your production environment? It happens and it's a bad time for experimentation. Usually such events lead to runbook updates. You learn some new stuff about exciting failure modes you did not consider before.
Having the practice of documenting non obvious things is what separates a good from an excellent engineer. I actually do it to help my future self as well. Because I know I'll go down a rabbit hole of reinventing things I already figured out a few months down the line.