There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.
It's actually doubtful it ever existed: its first formal description, in the 1970s, is used as an example of a model that doesn't work.
Let me formulate the Godwin-Udik's law:
"As an online discussion on development practices grows longer, the probability of a mention of waterfall as a negative example approaches 1"
Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).
I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.
Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.