Two starting assumptions
A default-deny posture starts from 'nothing is permitted' and requires an explicit rule to allow anything. A default-allow posture starts from the opposite assumption and requires an explicit rule to block what shouldn't be permitted. Both can be made to work for the cases someone thought to write a rule for. They diverge entirely for the cases nobody did.
Under default deny, a gap in the ruleset shows up as something failing to work — noticed quickly, because someone's legitimate task just broke. Under default allow, the same gap shows up as nothing at all: an unanticipated request simply succeeds, silently, and there is no natural signal that it should not have.
Why default allow persists anyway
Default deny costs more upfront: every legitimate use has to be explicitly enumerated before the system will do anything useful, which slows initial rollout and requires genuinely knowing the full set of things that should be allowed. Default allow is faster to stand up and easier to demo, which is why it remains common in systems built for speed of initial delivery over long-term safety — a tradeoff worth making consciously rather than by default.