We’ve always prioritized getting to production frequently. Lots of goodness flows from shipping early and often. The problems associated with shipping too frequently are so much easier to fix than the problems of shipping too infrequently.
When releases are infrequent, there is a natural tendency to “shrink to fit”; to cut a corner or create pressure to hit a release date, lest your code has to wait until the next release. Even a release calendar like e.g. “Release once per day, except Friday” is one bad Thursday release away from 5 days between releases — enough to create artificial pressure that works directly against all efforts to ship quality software.
Getting to production frequently means that releases are no big deal, and reverts are no big deal.
That’s not to say “more releases are always better” — we are already at a point where it’s impractical to manage when code is being released, and it’s challenging to determine the root cause of new exceptions because releases are so frequent. But the appropriate rate of releases is likely higher than intuition would suggest.