As someone who’s spent a lot of time as a sysadmin over the years, your last comment sounds backwards to me. The DevOps trend has pushed more general awareness and Docker has played a key role in three ways: making explicit automation requirements for the setup process (Dockerfiles have to work, unlike that MS Word document someone last updated 3 years ago), being private by default and requiring someone to reverse engineer the system to learn which things should be shared, and being immutable means that teams are forced to document shared state and backups rather than leaving messes behind for ops to deal with.

The key to understanding the benefit is the power of having done this in a standard, widely used way which is supported by many tools, used by an increasing fraction of projects, and which makes knowledge and training broadly portable. Some shops had some of those benefits but most fell short in multiple areas, ran into arguments with vendors / contractors, or required substantial ramp-up time for anyone new. Distribution packaging solves some problems very well - there’s a reason almost everyone uses it inside containers - but it has well-known problems with conflict resolution and coordination which are not easy to solve, tending to lead to inflexible policies and restrictions. Having a standard answer for the boundaries between generic system-level and application-specific concerns has been a great way to improve both sides while saving a good deal of time.