I think the issue for a lot of sysadmins is that trends have ultimately resulted in them losing the practical ability to manage what the software is doing security wise, but are still left accountable for mistakes. There is a great deal of pressure in the industry to be fast, and to be fast, just let the developers own deployment of their own software, enabling various technologies to let the 'user' be 'root' in some special domain to give them freedom.. However, somehow the admins continue to stay on the hook for problems that arise from how that software is deployed, despite having no control over deployment. So an admin in such a position is justified to quiz the developers to make sure *they* understand what they are doing to themselves, and perhaps lead them to more deeply understand the lego block modules they are haphazardly slapping together. Those modules are of widely varying levels of quality and commitment, and no good way to know at a glance if it's a wise decision to use them or not. Even when they are done well, any tool used incorrectly can lead to trouble. Of course, in these cases, the admin staff would take the heat, so they are actually making the correct call on their end, since they are shielded from those sorts of consequences.
That's not to say that there aren't a lot of good things in these trends, but there hasn't been enough interest in keeping the good bits of the way things used to work and *way* too much confidence in random anonymous peoples' development, support, and test skills and methodologies. If the developers are empowered, they should also be the ones to face consequences. The admin staff can be held accountable for the infrastructure bits they own, but generally speaking they have no real control over any facet of an internet facing service (in select environments, I do know a lot of places where the admins still manage things very thoroughly, much to the chagrin of the application owners).