Since they're lighter weight it's easier to run more of them. Think of a place with 7-8 different applications, a few different DBs to support them, redis, elastic search, etc. You can spin up a mirror of your production environment with one command. Theoretically you can do the same with VMs but it will consume a lot more resources.

This is only true of Docker on Linux hosts.

Even on Windows/Mac you're probably better off running 1 VM and then docker inside of it.

Isn't that essentially what mac Docker Desktop does?

Correct.

Speaking for myself, containers are started and destroyed faster. When using VMs, the tendency is to keep updating the software within the VM, making changes to their state, etc: this eventually leads to drifts. When using containers, if you need to make a change, you destroy the container and re-build it, and the state is always consistent with what you (and possibly your teammates) use

as an addition to do this, we've found it easier to spin up the same exact environment for CI/CD.

To be perfectly honest, in this scenario, there isn't much of an advantage.

The container approach is lighter weight, and I found it easier to manage the configuration via Dockerfiles. Managing a full VM with the OS install is a bit of a pain.

That being said, I worked at an organization that did the VM approach using Vagrant. It wasn't as nice as the VS Code/Docker approach, but the results were similar.