You know it's interesting. I used to work in finance. We, like you it seems, had a very locked down production environment with huge amounts of testing - pushing builds through multiple stages, reviews and signoffs. Once every month or so we'd shut everything down for a few hours in the middle of the night and roll the world forward. Stability was everything. Downtime was OK if scheduled, a disaster if not.
Now I work at a web company. We push to prod multiple times per day. There's a process, there are reviews and approvals, but it all happens much more quickly and at a more granular level. Change is constant but small, as opposed to infrequent but total. What's more we're a 24/7 operation so no downtime (as visible to the user) is acceptable. We simply can't schedule a few hours to do our rollout - everything has to happen live.
You know what I've noticed? We're no less reliable, overall, than the bank was. Yes we have issues, but they tend to be noticed, and fixed, much much faster. When you change everything all at once you run the risk of not being able to figure out what broke when inevitably something does. Rollback is painful because you have so many interdependent changes - in the end you have to pull the whole release to avoid one small issue in a single module. When you roll frequently the scale of change is small so isolating the bug is trivial, and rolling it back the same. Now of course there are huge differences in risk when you're handling people's money vs their cat photos, but I think the view that people working on an agile schedule don't care about stability, and that the only way to achieve stability is through reducing the frequency of change, is demonstrably wrong.