[Phlebsy]

There are different levels of risk involved with different types of changes, and there's also risk involved in not making some changes. But aside from that, it is useful to separate the meaning of deployments(pushing a build from a code change to production) from releases(enabling the functionality of that code for users/consumers).

Releases? Sure, you want those to happen early in the week so that you can monitor the rollout and how users interact with it. Deployments? Ideally, deployments change absolutely nothing about the performance characteristics of the system until a feature flag is enabled. There is some cruft in that and it requires cleaning up after yourselves, but when used right it's no different from standing up a new deployable that nobody interacts with yet as far as risk goes.

All in all, if you have a healthy CI/CD setup, use risk mitigating strategies such as feature flags/automated rollbacks, good monitoring/alerting on performance and SLOs, and you're not introducing something like 200+ novel lines of code to an existing workload running in production then I don't see the point in waiting to deploy.

Maybe I'm just too much of a fan of finding things that hurt and making them hurt as much as possible so that we are incentivized to improve them though. If something goes wrong on a deployment/release on Friday, it would go wrong on Monday too. Find what was broken about your process that let it slip through and fix that.