I get this a lot while reading about something new which I have heard might solve my problem, or while better trying to understand a system already in place. The documentation begins with a comforting high level description that is vague enough to sound like it might fit my use case, but then abruptly transitions into a table of contents listing the minutiae of interfaces, API calls, system components, without giving a suitable intermediary description of how any of these things might work in concert to actually solve the problem. This is left as an exercise to the reader.
You will almost never be offered any central insight from the author(s) about their mental framework for the system they have designed, or even that of the problem that it is intended to solve (so that you might more quickly determine whether your particular problem is a member of this class). Instead, I will often find this missing information presented in a random blog of some individual who, having won this knowledge through heroic effort, is determined to provide the context that they would have wished to find themselves upon first starting their journey.
Why does it have to be this difficult?
I suspect a lot of this has to do with the organization of companies involved (Google and Microsoft are some of the worst offenders here) in that the people writing the documentation are often not the people creating the systems, and so don't really understanding anything they are describing themselves. Meanwhile, those that designed the system suffer from the Curse of Expertise where their familiarity blinds them to things that are "obvious" to them, but are not actually inherent to the system they have designed. They are ignorant of all of the background understanding and experience that lead them to design the system or approach the problem in a particular way, when this is actually the most valuable thing I look for in any documentation I read.