Closure docs are pretty thin, mostly extracted symbols from code, with cryptic or misleading explanations. But a least you have clickable API listings.
I don't think this is fair at all. The Closure Library may have its dark and dusty corners, particularly for recently added/less used components, but on the whole, the library API is quite well-documented. You are mistaken about the API docs being generated from extracted code symbols; rather, it is all pulled from standard JSDoc tags. The library authors are meticulous about defining custom types rather than using ad-hoc enums and the like in their code, making the codebase itself very comfortable to reason about and making these @param and @return types very clear in their meaning.
I have my complaints about the library (certain dusty corners of goog.ui and goog.editor have hard-coded CSS classNames and Google URLs, meaning you have to use a patch queue to customize them) but I'm very pleased with the API documentation and examples. Google admittedly leans on Bolin's book (O'Reilly, 2010) too much for the community's manual-style documentation, but this is less crucial for a library than the API docs, and that book is really good :^)
The library has an extensive demo collection which is pretty nice too, and the demos generally include a minimum of 2-3 examples to show different ways to use library components (decorating vs. rendering usage of goog.ui package, for instance).
Google's real failure with Closure Tools has been marketing, but that is not my concern very much as a user. However, I see how this affects the library's adoption, so I've created a page at https://oinksoft.com/closure-tools/irc/ (I op the IRC channel) where I hope to aggregate more resources over time so that new users are able to get up-and-running without using Bolin's book.
