Depends on the project and the audience.
One thing I've learned over the years (but have yet to master) is that at some point, I won't be at my current job and somebody else will need to pick up where I left off. Providing sufficient (not necessarily extensive, but sufficient) documentation is key to me not getting phone calls or emails for several months. I'm not talking about code documentation, per se, but documenting my job, what I do, where things are located on the network, what processes happen, who to contact when things fail, etc.
For code documentation, if the project is public, that is, for other developers, such as an API, then absolutely extensive documentation is necessary. If the project is internal, then maybe not so much.
I also believe in user guides, but I leave writing those to someone else more suited to that task.