Cost benefit analysis. You get process isolation, remote execution. The cost: additional complexity. More cost processes are isolated so integration is harder, remote execution instead of local, etc.
It is easy to hype things if you do not consider the additional complexity, and then do not consider the corresponding down sides of the benefits in the "... long list".
Note that while I do not use Dev Containers, I use docker extensively in development process. The point I am making is that it is not a simple cost/benefit analysis.
I'm not hyping anything. This is how I've worked for over two decades now. Every time I've deviated from this path, it's been annoying and painful.
It's great to see products like GitHub start to bake it in. In my context, the cloud hosted solution makes perfect sense. I'm a GCP user, and Google has a competing offering that I would use in a heartbeat if GitHub would allow for direct integration, or if Google would get off their ass and launch a GitHub competitor / purchase GitLab and make it a first-party offering integrated directly with Cloud Workstations.
I've used VMs on Windows, netboot on *bsd without VMs, Vagrant on Mac, and random wrappers around Docker. Personally, I like that MS has integrated VS code with the remote execution part. For developers that want that style of IDE, it's freaking magic. For the rest of us, you can just continue using vim/emacs like you always did.
My other personal favorite, is using the same base VM/container image you use for dev environments for your CI/build environment. Guaranteed to have the exact same tools/versions available in both places. Let's you easily do testing/validation before updating / changing things. Makes on-boarding new developers easier. Makes recovering from a lost workstation trivial. Allows you to scale your dev environment on-demand vs. over-provisioning your dev workstations and barely using them. Makes isolating your dev environments behind a firewall/vpn much easier.
It's not a _simple_ cost/benefit analysis. But it's still just a cost/benefit analysis.
Personally, I wish the GitHub Desktop application on Mac/Windows had the ability to launch local workstations using a cache of your repo's devcontainers in the event you want to try and work off-line, or if you actually have headroom on your local machine that you want to use.
Even if you are doing native app development, a lot of folks still use VMs because testing on different OS versions is such a PITA. The nice thing about this approach, is you aren't just walling off the version of your test environment, you're also walling off the version of your dev tooling and all the supporting bits.
Oh, and last but not least, I can do my work assuming a Linux environment regardless of whether I'm hosting on Windows/Mac/Linux.
If I'm here to hype anything, its to convince developers who use Macs to stop trying to treat it like a Unix. Put your Unix in a VM and treat your Mac like a Mac. Life is so much easier.
Using nix ups the complexity of a project by so much.
Most folks who would be attracted to this solution are already using containers.
Personally, for me, this solution is basically the "Cloud Vagrant" solution that Hashicorp should have launched something over a decade ago, but couldn't get out of their own way to do. Whether it's containers or VMs, it just makes sense.
It's made sense for a long time. We started using VMs for dev work when I was deploying servers on Windows back in the early 2000s. Registry chaos, dealing with patches, and having to sit through multi-DVD installs of Visual Studio tooling just made this make sense.
Personally, I don't understand people that do development work without at least a VM. If not a VM, a netboot remote host that you can restore to a known state really quickly without interfering with your "productivity" desktop (email, calendar, chat, videoconf, document editing, browser, &c.).
You get process isolation, remote execution, the ability to cache and restore your environment… a long list of added benefits of using a container.