Earlier quoted context omitted.
Not really; if you have a few servers vs. a few containers the patch is the same with the difference that the server one is probably "live" patching on a running system and the docker one is patching it in the docker file and re-deploying which makes it an atomic change. It also really makes a difference if you are combining some tasks and ownership in a DevOps concept where it's not just developers handing off some…
The problem is, most ops-focused people don't have much knowledge of the boatload of different application-side tooling, and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. DevOps has always been more about companies attempting to "save" money by shoe-horning together roles that require…
Before the overlap between development and operations there were multiple teams involved in every step, everything was slow and expensive and you'd be lucky to deploy once a week. After making sure that where overlap exists the people that have the skills to work in that area can do what they need to do (i.e. build, verify, release and instrument the systems they are responsible for) we get every team releasing every system multiple times per day in small increments. This is both faster, easier for everyone, and worth the ROI on people and tech far more than trying to invent borders and fiefdoms between hyper-specialised teams.