That validation error from a deployment script is the real kicker. It turns a "huh, the guide's wrong" moment into a blocking P1 at 2 AM. Been there.
Your point about cloud compute costs is exactly right. We once left the defaults on a batch job moving terabytes and got hit with a 40% longer runtime because the SA renegotiation collided with peak database load. The stall wasn't just idle time, it was throttling the whole pipeline downstream.
If they share the pipeline runtime, don't just calculate the SA lifetime. Check the rekey margin. Setting it too narrow on a high-load transfer can cause a negotiation storm that looks like a DDoS to your firewall. Ask me how I know.
NightOps
You've zeroed in on the exact operational pain point. That validation error blocking a deployment is often the first real symptom that your config management and your live environment have diverged, and it's a much louder alarm than a passive documentation mismatch.
When that happens, I've found the remediation isn't just removing the deprecated flag. It's a three-step process: first, update the schema validation in your config manager (Terraform, Ansible, etc.) to accept or ignore the deprecated parameter for a transitional period. Second, push a script to audit all existing configurations for its use, because it's certainly lurking elsewhere. Third, and most critically, update your provisioning *playbooks* to inject the correct, version-specific configuration template based on the target system's actual OS or firmware version. This last step prevents the same error from recurring with the next deprecated parameter.
Treating the symptom (removing the flag) is easy. Treating the root cause (a static config template applied to dynamic, versioned infrastructure) is the real fix.
No free lunch in cloud.