The 2017 state of devops report says there's about a 31-45% "change failure rate." While that intuitively sounds about right, are they tracked as incidents? Nah. Because they get fixed pretty quickly, usually during validation.
An issue that gets fixed quickly is still an issue. If you're not reporting these as such, that's a problem.
So, it takes discipline to report failure rates accurately. We're disincentivized to report like that because we want things to work and we do what it takes to make it happen.
If your goal is actually to have things work, then you need to be honest about failures so you can prevent them in the future. It sounds like the team here is lying (perhaps to themselves, certainly to management) about failures because their goal is to have things appear to be working.
These are different things. For instance, take the old joke that QA produces bugs - "my code was fine until QA got ahold of it, and then they made all these bugs!". The bugs were there all along, but the developer was ignorant of them. An operations team's goal should be actual reliability, and they need to be incentivized as such by their management. That means that if they put more monitoring in place that leads to discovering new issues, they should be rewarded, not penalized for the subsequent drop in reliability metrics.
TL;DR, how do you prove devops, specifically deployment automation, improves change failure rates?
If you're trying to motivate change in your organization, then you shouldn't be trying to prove anything, but provide evidence of what other organizations say about their own transitions. If you're trying to measure the processes that you already have in place and justify their continued existence, then you should be tracking the standard reliability metrics, like mean time to repair (MTTR).
But devops principles are not merely about increasing reliability. Even site reliability engineering is not merely about increasing reliability. Rather, you want to get to an appropriate level of reliability - something that benefits the business but doesn't hinder development. And that brings up the real motivator in devops, which is to empower change. You want to allow the business to respond quicker to market stimuli, which happens by decreasing developer friction, increasing the rate of deploys, automating manual processes, etc. while staying within an acceptable bound of reliability. This means you need to measure reliability, but you also need to measure velocity, because your goal is to increase the latter while keeping the former relatively static.