The unfortunate reality is that in order to get many decision makers to support something, you need to show them quantitative data about its value.
In a past life, I worked on the performance team at an enterprise software company. For some of our users, our main dashboard took almost a minute to load. Fixing this didn't generate any new sales or increase revenue (enterprise software like this is sold to CTOs, not employees, and the actual product quality rarely affects sales numbers). We had our PM work full time to come up with numbers supporting our argument that making the service fast decreases churn. It was a pointless exercise, but it got us the resources to help fix the problem.
The sad reality is that while there are many things whose value should be intuitively obvious, the folks in charge do not always have an appreciation for them without seeing hard numbers.
The problem with enterprise software is the same problem with most issues we see from the producer side - those doing the work are completely different in alignment and requirements / needs than those that make the decisions to purchase for those. In Agile (and devops), the greatest friction is squarely around the reality that there's a manager caste that pushes down and makes decisions with very little feedback loops or misaligned incentives by all the stakeholders involved, and this causes churn within the group. For the buyers and the users of the software, their requirements are oftentimes lost. In your scenario, users with more power over their day-to-day software will demand better software and be empowered to select alternatives, but in more traditional organizations there will be a lot less churn comparatively because users will simply put up with bad things forcibly.
Almost all the "radical" software and project management practices to show up (and when implemented successfully at least) in the past 15 years aims to give more power to workers and to de-scope the role of management from pure decision-makers into a more supportive role with more intense feedback. There is a very consistent theme that organizations where these efforts fail are ones where management uses new processes and tooling to exert their existing political power to achieve results instead of also transforming themselves.
Often ROI is not realized on the short-term but rather the long tail. Users may not bounce immediately... however whether they stick with a product or not over time, may be a result of how usable it is. Same with if they would recommend it to a colleague or family member over a longer period of time. These things can be harder to quantify and are often omitted in ROI analysis.
In a past life, I worked on the performance team at an enterprise software company. For some of our users, our main dashboard took almost a minute to load. Fixing this didn't generate any new sales or increase revenue (enterprise software like this is sold to CTOs, not employees, and the actual product quality rarely affects sales numbers). We had our PM work full time to come up with numbers supporting our argument that making the service fast decreases churn. It was a pointless exercise, but it got us the resources to help fix the problem.
The sad reality is that while there are many things whose value should be intuitively obvious, the folks in charge do not always have an appreciation for them without seeing hard numbers.