EDIT: I misunderstood the original question; although I think generating documentation (i.e. non-code documents) can be extremely valuable (see original answer regarding Doxygen below), auto-generating comments (which is something that GhostDoc actually does) sounds insane to me. I cannot understand why anyone would expect a program to be able to read un-commented source code and write comments that will genuinely clarify it.
It is conceivable to me that an extremely "smart" comment-generation utility could be programmed to recognize certain patterns and generate "how"-style comments; for instance, it could recognize Knuth's variance-calculating algorithm and provide a comment explaining how it works and why the naive algorithm wouldn't be appropriate. Perhaps such a utility could even be programmed to recognize canonical object-oriented design patterns (e.g. Abstract Factory) and insert comments indicating what pattern is being used and which classes are playing what roles.
But in my opinion, the most useful comments don't explain "how" something works, since the code itself should show this, but "why" comments, explaining "why" a particular thing is being done. As noted by David Hammen in the comments below, in order to generate "why" comments, a utility would need to "read the programmer's mind." Obviously this is impossible.
Based on the given examples, however, it appears that GhostDoc doesn't even accomplish the task of creating true "how"-style comments. So it is, in my opinion, worse than useless, since what it does generate can be inane and misleading (as in the second example).
Original answer: why automatic documentation extraction and formatting is a good idea
My software team uses Doxygen. The primary reason for this is that we need non-source-code (i.e. readable by non-programmers) documentation of code features/behavior/etc, but we feel that it is a better practice to integrate this into the source code itself than to maintain it as a second document. This helps us keep the documentation in sync with the source code (though of course that can't ever be completely ensured, much less automated) and minimizes the overhead of writing documentation (since documentation for a piece of code can be trivially incorporated into the file containing the code itself).
So the focus of our Doxygen use is not to extract information from code itself, but to keep documentation of source code as close as possible to the source code itself.
This also allows us to use one single tool to create both a "theory of operations" that describes our entire codebase and several sets of "release notes" that describe the software product but in fact do not contain any actual "code documentation" in the typical sense.
As for why we would need non-source-code documentation of the behavior of our code, there are two reasons:
- Our product is not merely software; it's a complex tool that integrates many hardware components, including some fancy lasers and fluidics. We need engineers without much software background to have a good understanding of exactly how the internals of our code behave, and telling them "read the source code" is not going to accomplish this.
- We must follow quite a few quality regulations, some internally mandated by the company and others legally mandated by the federal government. Although the quality process is (or at least can be) extremely valuable and helpful, it involves a non-negligible amount of overhead, part of which is the duty of the software team to provide this kind of detailed documentation of the software. Again, integrating this documentation with the code itself minimizes overhead and helps us keep the documentation up-to-date.
Note that the second bullet point is pretty similar to the point a couple other answers have made about managers wanting the reassurance (/bragging rights) of knowing that some documentation (regardless of quality) exists for every piece of source code; that way of framing it, however, ignores the fact that externally-mandated documentation can actually have some legitimate advantages.