My approach is I want the document to be idiot proof and to cover the exact steps to recover from a disaster.
If I get woke up at 2:00 AM, I am groggy and a lot more prone to errors than at 2:00 PM when I'm on my 3rd cup of coffee. At 2:00 AM it is much more likely I will make a mistake. Therefore having a document I can follow will make it much nicer.
On the other hand, capturing every possible disaster and recovery may be overkill; it depends on your environment. Like if my test/dev environment died, it would be annoying but not a "wake me up at 2:00 AM' type of problem. And it depends on what the disaster is. Did the database die? Did the instance die? Did the VM die? Did the VM host die? Did the SAN die? Did the server room die? etc. I can document what I am responsible for so I am starting my document at the "restoring Instance from backup" step. and once the instance is up, the document should explain how to bring databases back up. Then if a disaster hits, if the instances are still good, but the database is toast, I can start at the database level. If the VM died, I need IT to bring the VM back from backup (or worst case - from scratch) and once the VM is ready, I can go into the Instance recovery steps and Database recovery steps as needed.
Plus I have a "post disaster checklist" where I make a new full backup of anything that went down and run checkdb on every instance that was down.
My secondary goal is if I am on vacation and unreachable and a disaster hits, I want any other DBA to be able to grab the document and figure things out. I'm not going to be putting absolutely everything in there (turn on laptop, start VPN, RDP to work desktop, start SSMS, etc... those steps should be expected), but anything that I feel is a step to recovery. During a disaster, I don't want the stress of my boss standing over my shoulder watching me work and struggle to remember things as I am waking up.