If you are terrible at writing docs, then that’s your fault, not the style guide’s for enforcing documentation. Some fields might be self-explanatory and the docs for them might be pointless, but it’s better to be overzealous here rather than allow people to skip documenting stuff, because then nothing will be documented.
Also, the requirement to have documentation comments is just one rule out of hundreds, so why focus on that one?
I dissagree that its better to be overzealous here, because it re-enforces the habbit of writing subpar docstrings. Alternatively, if you always do the work (and it is work) to make excellent docstrings, it will affect the way you write code by discouraging splitting code into small obvious functions. It just makes it slightly more annoying.
Just as with comments I think you should assume the reader is a somewhat competent human beeing. Explain what needs to be explained, and make a *conscious* decision about it. For most public functions I agree that this usually involves a docstring, but not always.
Actually, I am quite good at writing docs. That is why I hate mandated comments in certain places. I would like to write better docs than that. In fact your comment tells me you (or perhaps your colleagues) are the one who is terrible at writing docs. "because then nothing will be documented" says it all. I actually would write docs voluntarily and they would actually be helpful.
Why focus on that one? Because it turns out that rule will force me to have 50% of the text that I see in a file be these useless comments.
Some things can’t be linted and require a code reviewer to point them out. Noting the absence of documentation where it is clearly needed would be one of those things.
Also, the requirement to have documentation comments is just one rule out of hundreds, so why focus on that one?