Government projects work that way for a good reason: unlike commercial projects, they do not prioritise making profits (after all, profits don't really exist in that field). I don't mean to suggest that they are perfect, or don't have the problems you suggest - simply that unlike commercial projects, you can't make the same considerations.

Say you are developing software for a public health body for example. In the commercial world you can sit back and not worry if the customer ends up with problems; sure, it's not desirable, but to your company it's an inconvenience. To a government, that may mean dead citizens, and unlike a commercial company they will prioritise that far higher. Better for the project - in this context - not to be perfectly finished or working than to have to it be faulty or incorrectly documented.

Commercial reality, of course, doesn't mean that Agile environments end up with zero documentation. It means they end up with badly maintained and incomplete documentation - and yes, that actually *is* worse than non-working software, unless you are building your customer a Hello World project.

There's very little use in working software - a software designed to be continually built upon, reiterated, etc - if the price of making it work is to have documentation so poor that making the next release is prohibitively difficult and/or expensive.

It should be clear that this comes with the caveat of what kind of software it is - e.g. some software isn't designed to have super-frequent updates, in which case prioritising documentation over working software can be said to be less important, but I wouldn't argue that that applies to much of today's commercial software.