I suppose the main issue with this kind of approach is cost - a powerful enough AWS instance is really expensive. But you can get beefy dedicated servers from Hetzner for 100/mo that might be a good option for smaller shops.
I find devboxes hold a few advantages over running Docker locally:
1. We can have multiple devboxes to aid switching between branches.
2. Services are more easily spun up and down as needed. If I’m only working on the API, I don’t have to waste local resources on the frontend.
3. Devboxes replicate more of the service networking (Consul) to aid debugging (versus using container networking).
The benefit of remote dev, along with standardizing on an editor, is that the company and IT department can say "here is a thing that works, use this one", instead of debugging weird issues on individual developer laptops.
If you're IT and someone comes to you and says their mouse doesn't work, do you break out the screwdriver and open it up to try and fix their mouse, or do you just give them a new one that you know works, so they can get back to work while you look into the problem later.
Local dev is great when you're at a small company and just starting out, no support, but once you're a software dev working alongside other software devs, most of whom are smarter than you, and then there's a whole other team of devs dedicated to your experience as a developer; local dev feels like a little folksy hometown sort of endeavor.
Don't get me wrong, local dev has its place, and some things like writing firmware will always want that, but the industry's moving past it for big picture reasons.
That's why having a remote VM doesn't really solve anything, there will always be employee-specific issues.
I guess it's less important when working in mostly hermetic languages/runtimes like Java. But for things with native dependencies or lots of required tooling where local setup can be a large pain, it really does help a lot.
For the dev it becomes: Install VSCode, request VM, done.