The references I'd direct you to are NIST 800-53r5 controls CM-3 (Configuration Change Control) and CM-4 (Impact Analyses) along with their enhancements, require that configuration changes go through documented approval, security impact analysis, and testing before implementation. A certificate change is unfortunately consider a configuration change to the services.

Each change needs a documented approval trail. While you can get pre-approval for automated rotations as a class of changes, many auditors interpret the controls conservatively and want to see individual change tickets for each cert rotation, even routine ones.

Yes, those rules always come from legal.

In some regulated places, someone is legally responsible for authorizing a change in production.

If it fails, that person's on the hook. So the usual way is to have a manual authorization for every change. Yes, it's a PITA.

One place I've worked changed their process to automatically allow changes in some specific parts for a specific period during the development of a new app.

And for some magical reasons, the person usually associated with such legal responsibility are the one that don't trust automatic process.