I just learned about Cynfin, and it actually pretty well describes my experiences with how people coming from big companies (think FAANG) handle situations in small startups. They are all about writing documentation, setting up processes and runbooks, yet to realize that many of these will become obsolete in matter of weeks. Yes, it is all well and important, and reaching stability is needed. However, many of small companies and startups are make-it-or-break-it.
Yes, there’s a spectrum, for sure. Runbooks make sense when you do something that is precarious and infrequent, or when you are dealing with a situation that requires investigation. It’s a midpoint between human action and automation.
That means the applicability of runbooks varies on the situation, the team, and, as you mention, how things are changing. Runbooks can be more flexible than automation (easier to change text than code), the price for that flexibility is they take longer to execute. Runbooks can be more rigorous than undirected human action, the price for that is they require maintenance.
I wrote a bit more about runbooks and their attributes here: https://www.transposit.com/blog/2019.11.14-what-makes-a-good-runbook/ and the team there has written some other good blog posts about the spectrum of automation: https://www.transposit.com/blog/2020.05.22-runbooks-devops-spectrum-of-automation/