Someone reading the code should also be capable of understanding the problem that it solves and documenting the use of the code. If your code is fairly well written, I mean.
Code, like say English poetry, can be subtle. Reading the code can easily answer the question "what does this do?", but it usually doesn't answer "why are we doing it?"
Most importantly it doesn't tell us what we're not doing here, and why not.
I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done.
But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on.
Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists.
It I'd if you like the "search index" into the code.
I think you misread the GP. These "mid and senior devs" are writing documents not documentation. They're not writing comments or wiki pages, they're writing designs docs for new systems, proposals for cross-cutting initiatives, etc. They're taking their knowledge of the domain, its issues, and general wisdom and applying it at a scale larger than a single developer's output.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
