Why continuous delivery is not enough?

Continuous Delivery has been treated as the best practice for almost a decade. I've seen a lot of teams who are doing it well. They have different types of tests to cover the business logic from UI to a database.  They follow the test pyramid quite well to have minimal effort with the maximal coverage. They are able to do a release with only one click if their product owners ask for.
However, when a system-wide refactor (such as changing to a better json library or a big version upgrade to a dependency) needs to be done, they show caution instead of confidence. Why is that? Shouldn't they do the change, push to CI, then deploy to production if it's green? If your team can have the confidence to do this, congratulations, you can remove the button before the production deployment and go one step ahead: Continuous Deployment.

There are more reasons to do Continuous Deployment as well:

• Real automation & 100% coverage - there would be no manual test allowed in any cases after pushing a commit. This force teams to automated really everything including visual testing for long term benefits.
• Better quality assurance - quality doesn't require any manual tests, there would be no human mistakes
• Easier to return tech debts - Fully test coverage help teams do any change without considering testing effort. This can reduce the cost of a system-wide refactor to less than a half. And more importantly, it changes the way to do a big refactor from a team delivering activity to a purely developing activity.
• Less waste - teams have no chance to implement anything without deploying to production. This would force the team and PO to work more closely to take the responsibility of releases together because the PO and the team need to find out the client impact/value of any change before the team push the commits. However, continuous delivery still opens the chance to the PO to change his/her mind in the last minute. 
• Get feedback before the implementation vs after the implementation - we have enough technologies to handle both situations well. We can easily create mock-ups with business flows to get early feedbacks of a design with very low cost. We can also have feature toggles to enable the later feedbacks from the PO and a small group of users with much higher cost. In fact, if the PO and the team work closely and have those early feedbacks, the team can remove one type of feature toggles (which is the switches of functionalities) and most other feature toggles will not be needed, so the value/cost ratio is increased.

So, are you ready to remove the one-click button? Do the following practices:

1. 100% business coverage - make sure you follow TDD all the time, even the css changes should also be covered by visual tests. And don't forget to automate all the non-functional requirements as well.
2. Zero downtime deployment - Most teams who achieved Continuous Delivery have already implemented this. If you haven't, do it because you will deploy many times each day and your users shouldn't feel that.
3. Monitoring & Alerting - do live check and health check for not just the service, also the dependencies to make sure you are notified if anything goes wrong

These practices give you the confidence to say a green CI build means that the application deployed to production with high quality and no customer impact, otherwise, you should get alert from your on-call system immediately.

In summary, Continuous Delivery is good but not enough to be excellent, you can improve your team's productivity by going forward to Continuous Deployment.