Catching it before pushing your changes is far more preferable.

There are a lot of different methods and processes to fix this. Docker is a new one that simplifies a number of the pieces of the puzzle by constraining the environment is useful ways.

However, if you already have a process worked out and aren't experiencing pain then you probably don't need to switch for the sake of switching.

That's true until something break in production: then you want to replicate the same situation in the dev environment, as close as possible.

Docker isn't magical, but the process that it lends itself to can be very useful. Those companies aren't using docker to be successful. They are successful because of the processes (and intensity) that docker fits into.

I'm sorry that your colleagues are being asked to drop everything and look at anything (much less Docker). That's not a nice way to work -- and I'm sure it influences their notions of Docker.