If you don't take time to read the entire manpage or at least skim through to find the optimal solution, then you're not experienced enough IMO. I understand the rush to come up with a quick win and amaze everyone, but the first quality I notice on senior engineers is that they were really slow in delivering solutions. The ROI would come up later when drawbacks were documented, the solution was well explained and most of the times elegant, hence no one would need to touch that part of system anytime soon and if someone did had to do so, he'd have a head-start.
Sometimes its not even the docs that suck, but the site hosting the docs. Microsoft used to be ready bad about this (they're a good but better now) and I swear it used to be impossible to find what I wanted on MSDN without a search engine. I recently also tried to build a certain gcc frontend, and the site had the strangest navigation. Top level links to each documentation section, but then you had to click two small forward and back buttons to continue reading the docs for that section. Ot took me a few minutes to figure that one out.
I have a piece of software and a task I want to accomplish. For example, list files ordered by size in ascending order. ls' man page tells me how to do that, but I have to piece the information together because it is arranged option by option. Thus, I'm forced to read more than what I'd like.
Or I can google "ls sort files by size" click on the first link https://alvinalexander.com/photos/linux-ls-command-how-sort-... and voila.
Most people writing docs don't get that people learn by example. Thus the docs they write lacks examples and therefore are not very useful.