Generally, I agree. I think what I meant by the above is "how would you tell someone how to use the thing". My favourite example is email vs email-with-PGP.

How do you send an email?

1. Open client
2. Click "send new email"
3. Type your email
4. Click send

How do you send a PGP-encrypted email

Let's first talk about this thing called a "keyserver". Once you know what that is, you'll have to go out and find some keys to add to it. We're not going to talk about styling your message 'cause that's not something you should be able to do... etc. etc.

The docs are not only often difficult for an inexperienced user, they commonly omit points of failure.

Various prerequisites, problematic settings, possibility of the user choosing the wrong menu etc. etc. should always be considered.

Good documentation should, in part, tell people where to click. I have designed software documentation for high performing individuals at leading global companies, and I have designed software and hardware documentation for minimum wage fast food workers with limited English proficiency. In both extremes, I showed them exactly where to click on the screen at each step.

You might not need that level of help, but many people do. Others do not strictly need it, but they prefer the simple instruction set. "Click here then here," instructions ease the transition into a new system one needs to learn, or it removes the need entirely to learn a system one uses infrequently.

The problem is that making good documentation is difficult and time consuming. It relies on a fundamentally different skill set than coding or even UI design.

I agree that the ideal is for software to not need any documentation. In my experience, I have yet to see software that rises to that task and is used across a variety of experience levels and societal cross sections.