I think high quality comes from specialists. Sharp knives in the hands of pro's
I suspect you don't mean it like that, but developers have to care just a little about operations. There's the classic stuff about developers who build stuff, because they didn't realize that ops could do the same with a few lines in a web server config, so they waste weeks on trivial stuff. There's also the issue that if you expect databases, queues, disks and so on to just be available, while not thinking about how you use them, then you can get bad performance or cause downtime and crashes in the worst case.
The initial idea of DevOps also seems to have been twisted to having developers do operations, rather than having the two teams work in tandem. If we absolutely must combine the two roles, I'd be more comfortable having operations do development work, but that hardly ideal either.
Yes, I'm cynical. Having to use javalike stuff to do what should be a simple shell script will do that to you.
In a huge organisation, it can work well to be very specialized.
In, for example, a smaller growing business with an engineering team of < 10, having a proper understanding of the context in which your code will run is a game-changer.
Like TDD the design of software changes when you have experience with ops/maintenance. Take logging/tracing: what to log or trace is first and foremost a matter of experience with maintenance/ops! Building in logging/tracing/monitoring from the get-go because you know that you want to know what goes wrong, when it goes wrong etc...
can one regard oneself as expert if you know only a part of the domain- I think not!
Maybe "before my time" it was a webmaster or other admin. I think of "dev ops" as an umbrella term subsuming many specific titles and roles from the past, much like "data science".