If your GUI program is simple and well-designed, then you normally don't need good documentation. However, a command line program, a library, etc. does need one, or else the user won't know what to do.

There are many types of documentation: the --help flag, the man page, the README/USAGE/INSTALL files, full-fledged in-depth guides, documents about the philosophy, wikis, etc. If the program is well-designed, then the user should be able to get up and running quickly. An exception to this is various highly specialised programs, such as 3-D graphics programs, or CADs, that require some learning.

If we take Subversion as an example, then it has a full Book online, several tutorials, an svn help command which provides help to all the other commands, and a lot of help can be found using a Google search. GNU Arch, on the other hand, only had one wordy tutorial, that I didn't want to read. Most of the other tutorials people wrote, became misleading or non-functional as the program broke backwards compatibility.

Vim has an excellent internal documentation system. It's the first thing you are directed see when invoking it. It has a comprehensive tutorial, a full manual, and the ability to search for many keywords, with a lot of redundancy. As a result, one can easily become better and better with vim or gvim, albeit many people can happily use it with only the bare essentials.

Emacs' help on the other hand is confusing, dis-organised, lacking in explanation and idiosyncratic. It doesn't get invoked when pressing "F1", is not directed to when the program starts, and most people cannot make heads nor tails of it. There is a short Emacs tutorial, but it isn't as extensive as Vim's. Nor does it explain how to configure Emacs to behave in a better way than its default way in which it behaves completely different to what people who are used to Windows-like conventions or vim-like conventions expect.