Further, they are not as adept with word processors as you might like. Therefor, you can expect their output to contain some paragraphs that are not in the proper style, some words that are not in the proper font, etc. Consider, for example, that Microsoft documentation is littered with examples of words that should be hyperlinks but aren't. Similar examples can be found in even the best produced documentation sets. But if you have programmers messing around in a word processor, that is exactly what you end up doing.
Engineers hate to do it - it's a dull, boring, and utterly thankless job.
Combine these factors with the fact that managers tend to stress that the importance of the documentation is in having it done, not in doing it right, developers get the idea that the whole process is a waste of time. It's inconsistent and incomplete - with comments in the code itself, you have far fewer problems with inconsistencies between the documentation and the code, but it still remains a challenge to make sure that the comments are always updated to reflect changes in the code. It's hard to read - having documentation isn't much good if you can't find it. Engineers hate to do it - it's still a thankless job and this time you can't even point to a nice looking result at the end of your efforts. Given that it is often easier to find the author of a function than it is to find and read the comment for the function, developers who write nice, useful and consistent comments are likely to end up wondering why they bother - their coworkers fail to read them and their managers only care about the code.