Reading documentation (ideally) is a form of acquiring knowledge as well. So you can't really separate the two. However, in some cases, documentation doesn't produce much useful knowledge in the reader. This isn't just because documentation can be wrong or out-of-date, but because a lot of time working with the thing hands-on is a more useful way of acquiring that knowledge. For example, software documentation is necessarily a summary or metaphor about the code (the worse the code is the more this is true, and the better the code is the more obvious the metaphors are from the code itself). Frequently the source code is a better source of knowledge than documentation of it. Though documentation can give you hints about why the source code works a certain way.

Also, nailing requirements down too hard up front can close off creative solutions. I'd rather get a vague "this is the problem we want to solve for the user" vs telling me where every button should be and agonizing over shades of blue. But then once the code is built, if you put in integration tests, they will necessarily document the requirements after the fact.