This is based on my experience with RHACS operator.

Policy management based purely on clicking in the GUI is antithetical to GitOps. Without policy-as-code one needs to manually click into the policy administration menu, into the system policies, and applying changes. Without policy-as-code these changes cannot be replicated automatically. Applying these changes to the 87 system policies is non-feasible. This is my argument for why policy-as-code is important.

Enabling policy-as-code today relies on manually clicking through and cloning system policies, downloading the CRD for the cloned policy, and checking the CRD into your repo for CI/CD [note: I have engineered a workaround for the clicking, but it shouldn't have to be that hard.], or applying the manifest locally (for testing or if you're that kind of engineer). This is my argument for why enabling policy-as-code should be easier, or having it be the default.

If the central instance was deployed with the system policies as CRDs in the cluster, rather than being baked into the image (as is my understanding of what happens based on /pkg/defaults/policies/policies.go), one could apply patches to manage these policies rather than being dependent on lengthy mouse clicking adventures, and avoid risks of config drift. This is my argument for a solution to this issue.