Containers have a rather narrow use case: efficient, decoupled deployment of Linux-hosted applications, particularly as part of a CI/CD pipeline. I would not expect most in "IT" to care too much about it, it's more of a "DevOps"/developer/SRE thing.
Containers are far from only being for linux applications, FreeBSD and illumos both have containers there just called jails and zones. Also FreeBSD and illumos sys admins use containers for application isolation because both jails and zones were designed to be secure.
There are configuration and package management systems (e.g. Salt or Ansible and apt or pip). Containers provide that + isolation, but I bet for majority cases no one cares if two services are walled from each other or not - as long as they don't interfere. Usually, they rarely do - and when it happens (say, an ancient blob wants an older libc), in most of cases a mere chroot does the trick, without need for cgroups/namespaces/extras.
There are lots of companies doing a lot more with containers than just using them in a pipeline. Google, for instance, runs all of its apps (including search) in containers (using Google's own container framework, LMCTFY), managed by Kubernetes.