I think we're talking about different things then. I don't think you need to document every single line of code. That would be insane and is absurdly pedantic. No one is suggesting you (more than) double the amount of text in a codebase.
But you should write summarize your abstractions. So that's your classes and functions. I agree with the other commenter that what is of most concern is the method's signature. Also, a naming might be obvious, but I assure you it is not. What is obvious to some is not obvious to others. In addition to this, the code changes over time. What once might have been obvious no longer is later down the line. Expect this to happen because you want to handle failure in your "system" (in this case, the style in which you write code). The more complexity in a method, the more important it is to document.
If you need an example I think both the main article AND the comments here are quite enlightening[0]. In fact, I'd say the comments perfectly prove the author's point. The author writes very clearly how when playing the game you should operate under purely the letter of the law but top comment claims crystal clarity yet mentions "intent." A point explicitly mentioned that one should ignore by the author.
Just think of documentation as information entropy. By adding a few words you increase the information gain for someone who has never before looked at the code. I've also given you reasons as to why you are likely to also benefit, so if you need a purely selfish reason to document, this too exists. But we must differentiate long term utility vs short term to see the reasoning.
Of course, a precondition is that the person reading the code knows the language reasonably well, and I'm not writing a language tutorial.