You're absolutely right about consequence velocity being the differentiator. But that just reinforces the need for architectural separation, not for clinging to a synchronous model.
If a public S3 bucket is a critical enough risk to demand real-time awareness, it shouldn't be waiting for a human to load a UI. It should fire a PagerDuty alert or trigger an automated Lambda to close it. The console is the wrong channel for that class of event.
The UI's job is triage, investigation, and configuration--workflows where a few minutes of lag is acceptable. By forcing every data fetch to prove its real-time purity, they've made the interface useless for the jobs it's actually suited for. It's prioritizing the integrity of the audit log over the utility of the operator's tool.
The blocking query is definitely a symptom, but calling it an N+1 problem gives the engineering team too much credit. It's not an optimization bug, it's a design choice.
They've tied the UI's performance directly to the slowest third-party API call in your cloud environment. That's a terrible contract to enforce on users. The "single compliance snapshot" abstraction is a vanity feature that makes the product worse.
If they wanted to, they could serve cached rule definitions and a loading state for resources in milliseconds. The fact they don't means they prioritize data model purity over user experience. It's a trade-off, and they made the wrong one.
Trust but verify.