Rationale regarding app registration permissions for dev/prod deployments

[SkiLikeTheFootwear]

I've been doing a proof of concept of EPAC since February 2024, which I believe started with a deployment of v9.1.0. I am presently deploying to two dev tenants and intend to deploy to a production tenant once everything is in place in the dev tenants. I'm looking for some clarification on the permissions required for the app registrations when deploying v10 with Azure DevOps pipelines.

I seem to remember successfully deploying v9.10 with a single app registration/service connection only having User.Read Graph API permissions and the Policy Insights Contributor role at the pseudo-root Management group scope of the tenant. Looking at the current documentation, I'm not sure how my deployment worked in the first place since it doesn't seem to work now on v10 despite updating the global-settings file. Did something drastic change with the required permissions between v9.1.0 and v10?

On closer inspection of the current documentation, I'm seeing that a recommended production deployment is broken up into a very restrictive three service connections/app registrations, one for each pipeline step, instead of one app registration will all necessary permissions. Recommendations for setting up a dev deployment seem to skew in the oppose direction of too permissive, with a single-app registration having the Owner role at the management group. I'm trying to understand:

1. Aside from implementing least-privilege for the sake of it, is there an engineering/architecture reason for what seems like an overly complicated production deployment?
2. Granting the overly broad Owner role in a dev deployment seems in direct contradiction of least-privilege principles. Shouldn't a deployment to a dev environment follow a similar structure to what is being deployed to production, so as to catch issues before they are deployed to production?

For context regarding my particular situation, my team is singularly responsible for Azure Policy across our Azure tenants, so while using an Azure DevOps pipeline and environments is useful, we will not need the rapid iteration and complexity of a full-blown CI/CD pipeline with branches, features, PRs, and other such complexity.

Thank you sincerely in advance for your input, I figure that others might have similar questions about some of the design decisions of EPAC.