The main pitch is that you don't have to spend time and effort with installing and configuring a project for development when onboarding new people to it, or when you want to contribute to someone else's project etc.

You get a proven, up-to-date "works on my machine" kind of environment that others also use, and you don't need to "pollute" your host system by installing additional tools necessary for each individual project. Compilation (and other build steps), running the project, running the tests, debugging, IDE configuration (e.g. language servers, linter plugins), etc. all happen inside the container.

I personally don't find it all that useful for projects I'm working on long-term myself, but it's nice if you need to check something in someone else's project which you're not that familiar with.

I use dev containers on Mac, it’s not just about launching services that you need to test your code, it’s about specifying the entire build toolchain to get a deterministic dev environment in an isolated way.

You don’t need to manage the docker containers at all, vscode handles their lifecycle.

You can specify different extensions/configurations per project, so if you bounce between several languages, you’re only using the extensions/configs for a given project.

It also allows for a mostly seamless debugger experience with the browser when you launch a process.

The nice thing is that it sits off to the side, you can use your docker-compose as you normally would, but if you want to provide a full working dev environment for contributors, basically all they need is docker and vscode installed and they can get started.

The devcontainer spec is based on open standards, so it probably will end up in other editors, because it solves a huge problem for teams. The only thing that I think will come close is Nix, but I think it’s limited in scope in some important ways for this use case.