As an example, we're a young company with some very old-school devs. Devs that would FTP push directly to prod and never commit to Git. To mitigate friction on transitioning these devs to more mature practices, management went heavy handed with documentation. Step by step instructions on how to commit, how to name your branches, how to hotfix, etc.
Well guess what? Our practices our different now. Our branch names differ, our git host is different and requires different practices. All the screenshots are out of date. The text is littered with old references and old practices, spread across a dozen documents.
In my experience trust in this sort of documentation is _easily_ lost. Lost trust means that a developer won't bother looking, and will end up asking a senior about it anyway.
On the flipside i love documentation that can be automated, filled with tests, etc. I use a Rust framework called Mdbook, which i include tests in to attempt to ensure when the schema or API changes, the tests fail so the dev remembers to update the documentation. Not perfect, but at least the tooling helps humans be better.