Well, they don't today. But you or someone who has to maintain it will tomorrow, and then the customers will follow when the quality of the product degrades because the code is unmaintainable and there is extremely high risk of breaking something accidentally when you go in to touch something seemingly unrelated.
I think developers have a difficult time communicating the business values of code quality, and what code quality means. I think senior developers often have a hard time communicating these things to junior devs as well, which creates a sense that the old timers are just dogmatic ideologues who don't have good reasons for asking for certain changes. I realized this when I once had a manager point out to me that I was coming across as some type of esoteric "purist" when I spoke of "clean code."
The value of software is its ability to change. Change is baked into software by definition. Otherwise we could just stick with fixed circuits and be done with it. They are cheaper to build and have practically zero maintenance costs (other than perhaps replacing hardware components that wear out). So every line of code is served by understanding when it is written that there is a high likelihood that it might need to change at some point.
There are a lot of causes of burnout in our industry, but one I hear often is that code maintenance is an nightmare, that debt tech is overwhelming and that leadership gets annoyed and just looks for "more developers" when new features they are asking for can't be delivered as quickly as they could when the project was greenfield, and that customers are complaining because the system doesn't scale and is running far slower than it did when they first bought in.
I guess what I'm trying to say is that readable, DRY maintainable, non-spaghetti code IS pragmatic.