It doesn't help that, at least in my experience, a lot of "pure" software developers absolutely want nothing to do with the ops side, preferring to work on new features and just code, and vice versa.
I greatly prefer it when the ops team tracks the time they spend on incidents, then stack ranks the ways in which my software sucks (in terms of hours of their time wasted), then asks me to fix it.
The same thing goes for $/perf discussions.
I don't care if they want to SCP or ftp or send my code over a QUIC tunnel through a bastion host on the moon.
If developers have to know there is a new or old way of doing that, then the CI/CD team has failed.
If you want me (the dev) to fix CI/CD, then I'll happily reimplement it with make and a fault tolerant NFS share. I'll even explain why that has been the best available approach since ~1985.
I have almost the exact opposite problem with some of my team, where they want to spend a lot more time on the Operational side. This is a mixed blessing - they'll learn the depths of various AWS things that are painfully boring to me - but I'd rather they were writing code instead of mucking around looking for some magic AWS solution to solve some specific use case.
Really? To my mind, code is a last resort from a business perspective: I’d much rather developers use AWS features when available.
This is true that from business perspective if there was a way to completely cut off engineers and replace them with low-code / saas offerings -> we all would be out of the job next week.
Fortunately for us engineering is quite complicated.