I think we need to distinguish between documentation and expressivity of the code.

When debugging or reviewing code, you're not reading a book. Most of the time you just want to jump from method to method and make quick connections in your mind to get a basic understanding of what's going on at runtime. It's not the documenting around the code but the expressivity of the code signatures that matters in that process, their ability to be meaningful enough that you can immediately identify them and add them to your own internal call stack. At that point, our brain (at least, mine works that way ;)) tends to consider large comment blocks as a noise rather than a help. Therefore, one-line comments, or even better, just self-descriptive method and object names are sufficient here.

If you want to "read the book" of a particular class or feature, a much better place for that is in the unit tests. Well-designed unit tests are by nature intention-revealing and much more documenting (ie explanatory, detailed) than the thickest of comment blocks since they contain 1/ the expectations on exactly what this code is supposed to do and 2/ the ability to check these expectations against the real code. A passing test is a hundred times more reliable than any comment in terms of documentation, because it proves that what it asserts is true.