Anecdotally, colleagues have successfully lobbied to drop (or not enforce) password expiration policies from other government bodies on the strength of this recommendation from NIST.
I was in a team whose security group eliminated the use of DVD drives for reading (not writing) data except for a few permitted individuals. Creating a massive chokepoint in every process where data had to come from off-network. Security didn't care, it took the realization of the cost (delays, people too busy moving data to do their actual jobs) for management to step in and end the nonsense.
The same will be required for things like password policies. Until the issue becomes realized (weak/written passwords lead to a compromise), these policies will stay in place within organizations and teams. It doesn't help that the majority of the policy setters are not IT professionals (or only in the loosest sense, they can install software but have no real understanding of IT systems). In DoD, most come from a physical security background (retired/separated security forces).
It's not that, it's inertia and poor incentive structures.
In a large organization, if a policy was set in place by someone else, then, even when you know it's a sub-par policy, it's still in your interest to leave it alone. Doing so gives you a way to deflect blame in the event of a breach related to that decision. You can just blame the policy itself. If, on the other hand, you change the policy, you're more likely to be held personally accountable.
That said, you're also absolutely right about the expertise problem. I don't know much about government, but, in private industry, I've observed that the best way to get put in charge of cybersecurity is to start from somewhere completely outside of IT, and become good friends with the CEO.
This is the psychological/economics point of view, and I think it's the correct one for this problem. The other tricky issue, besides the CYA prioritization, is that being a dynamic entity requires other entities to do the same. If you start changing procedures in your section, other sections that rely on you need to adapt to these, and they may have the CYA attitude and resist that change.
its much easier to keep it in place to make the auditors happy than remove it, and risk exceptions on your report that you have to defend.
edit: I wasn't calling OP a liar, I just couldn't find it.
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."
Without those other mitigations, pw rotation may still help more than it hinders, although I am definitely not a fan of it and recommend implementing all of the NIST’s recs instead.
For those looking to head that route, haveibeenpwned offers an API to check hashes against previous breaches. For a pw strength meter, have a look at zxcvbn.
My guess is the idea is to mitigate compromise of very old passwords, spray attacks using breached site creds, reduce insider threat and at least offer some mitigation for compromised hashes.
I think this is wise compared in work environments - 90 days, 180 or even 360 would be a good mitigation over _none_ to too many.