My take-aways after diving into toolchains
Docs as Code is indeed the best tool for many situations, but there are other tools and other situations.
Every tool has an ideal and proper use, and you should understand what tools were developed to do, even if you will never need them or don't want to use them.
Don't assume that you have the wrong tools in your shop, even if there are things you don't like about them. The tool was most likely adopted by your group for important reasons.
If you do find you have the wrong tools, remember that it's never the tool's fault. Your organization's needs might have changed, or your organization might not have a strong process for selecting tools. If the latter was an issue, proceed with caution and humility.
You can adopt more than one tool or toolchain if you have two kinds of authors with drastically different needs.
If you change tools, the ideal justification is a better customer experience and ease of use for the authors. If you don't see at least one of those benefits in a change, reconsider what you're doing.
The right people should be working on each set of docs. Engineers can have a big impact by contributing to the reference docs (e.g. Swagger specs.), but some kinds of documentation are better if they're written by technical writers. When you decide who writes the documentation, ask who can produce the most helpful documentation for the customer, and ask who can produce it quickly.
In case you missed them, here are the previous articles from this series about toolchains.
Knowing your toolchain requirements prevents misery