Having such scripts enables one to quickly setup a local environment to make changes and test them before submitting a Pull Request.
My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it doesn't fit exactly how they want to work.
Meanwhile everyone else will get back several hours of productivity per week.
Running on a remote environment may sidestep the issues of running on local hardware (poor virtualization, resource limitations, etc) but you'll have to standardize and automate the generation and management of your dev environments either way. Otherwise, you'll have the same problems in your remote space as you currently do locally, plus a few more possible points of failure (low latency network reqs, permissions differences, etc).
> My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it doesn't fit exactly how they want to work.
I'd expect internal support to be highly dependent on how terrible the alternative is. Beyond personal preferences, I'm really apprehensive about coupling all dev work to a single remote cloud provider. What happens if you lose internet access or when they inevitably go offline? In the case of the later, literally all work stops.
Works really really well when you allow your employees to explore and do what they want locally. Then when things break or go wrong (either I tweak something, or an incompatible Apple update lands) - I can just reset to the same dev env as everyone else.
It's fantastic. Spin up and throw away a dev env that is so much more powerful than my local machine could be (100+ GB RAM machines are a click away).