Yes people do this kind of thing, as far as I know they all do it in fairly different ways... but what you're describing sounds reasonable. Yes, it does tend to be expensive. The whole point, as you note, is that the env has grown to be large so you're hosting a bunch of personal large environments which gets pricey when (not if) people aren't tidy with them.
Some strategies I've seen people employ to limit the cost implications:
- Narrow the interface. Don't give devs direct access to the infra, but rather given them build/tooling that saves some very rich observability data from each run. Think not just metrics/logs, but configurable tracing/debugging as well. This does limit certain debugging techniques by not granting full/unfettered access to the environment for your devs, but it now makes clear when an env is "in use". Once the CI/build job is complete, the env can be reused or torn down and only the observability data/artifacts need to be retained, which is much cheaper.
- Use pools of envs rather than personal envs. You still have to solve the problem of knowing when an env is "in use", and now also have scheduling/reservation challenges that need to be addressed.
- Or automatically tear down "idle" envs. The definition of "idle" is going to get complex, and your definitely going to tear down an env that someone still wants at some point. But if you establish the precedent that envs gets destroyed by default after some max-lifetime unless renewed, you can encourage people to treat them as ephemeral resources rather than a home away from home.
None of these approaches are trivial to implement, and all have serious tradeoffs even when done well. But fundamentally, you can't carry the cavalier attitude of how you treat your laptop as a dev env into the "cloud" (even if it's a private cloud). Rather, the dev envs need to be immutable and ephemeral by default, those properties need to be enforced by frequent refreshes so people acclimate to the constraints they imply, and you need some kind of way to reserve, schedule, and do idle detection on the dev envs so they can be efficiently shared and reaped. Getting a version of these things that work can be a significant culture shock for eng teams used to extended intermittent debugging sessions and installing random tools on their laptop and having them available forever.