I have first-hand experience with the problems of designing systems for adversarial denied environments. These are largely orthogonal to the problem of access controls. The low-level communication security and channel capacity is handled almost exclusively by external trusted modules, systems built on top of them only have to concern themselves with the behavior of these modules.

There is a separate concern around denied data environments in the software realm but that is not on many people's radar. Most software devs would not know where to even start to protect systems from this.

A tension with access controls is that if you implement it to the level of granularity the most demanding parts of DoD say they want, it never actually gets used because it is too complicated for users to reason about and manage. Or worse, they make mistakes and leak data because it is complicated. A simpler model is always implemented on top of it. At the same time, fine-grained and scalable access controls impose a high operational cost in the software even if they are not being used and some parts of DoD care a lot about software performance. Many parts of DoD are realistic enough to not want to pay for access controls they'll never actually use.

On top of this, security architecture is designed to be somewhat pluggable because different users will have mutually exclusive design requirements for the security architecture. It would be nice if this wasn't the case but it is what it is.