|more useful options|
If (module/unit) documentation only ever consisted of interface specifications, then (perhaps), POD would be fine. But, all too frequently, it also has to contain a mountain of stuff that is essentially unrelated to the code.
Whether it's algorithm explainations, or market research, or comparative studies or whatever else might be useful or required by the users of a module. But often this stuff is of no consequence to the programmer maintaining the module.
To conflate user documentation with programmer documentation is a bad idea. Even if the modules users are also programmers at the next level up, mixing the two types of documentation together means that it serves neither group well.
There's also the problem that purely textual changes, from typos to reattributions to rephrasing of prose can trigger RCS trails associated with the code that shouldn't be. Documentation also belongs in the RCS system, but as independant entities to the code, so that documentation changes do not affect the revision history of the code and vice versa.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.