That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software implementations of the time.
While design documentation tends to be anti-agile (but sometimes useful to avoid wasting more time on miscommunication and mistakes), end user documentation is, for all practical purposes, part of the valuable software product, as it enables end users to do what they want to do.
Unfortunately, being able to neglect end user documentation makes many outfits treat it as a useless luxury, either because they are only judged on software (e.g. passing a test instead of having satisfied users) or because they don't care (e.g. many introverted hacker/artist open source maintainers). It's purely delusional agility, like driving fast by not stopping for fuel.
