If you do that then you undermine the idea of being able to do lightweight debugging etc., and there's no particular merit to matching your servers. You need a reasonably stable workstation environment, but it doesn't really matter if different developers use whatever they're most comfortable with as long as it makes them productive, and people will probably want more up-to-date tools than what's available in Debian Stable. (In practice a lot of people who follow this model end up using Macbooks, and it's... fine, not an awful way of working, but not the clear best either).

> Applying global changes to your system (e.g. using package manager to install a specific versions of packages required by your production app) is a terrible, terrible idea that will cost you more than isolation (standardized docker, dev VMs or similar, which ought to reflect your running environment).

Why? Your system is (or should be) a single-purpose tool. It absolutely should be managed and reproducible (using something like puppet), but keeping everything flat so that you're working on the same "bare metal" that your application works on has more advantages than disadvantages IME. (E.g. it's hugely helpful to be able to fire up a random REPL, integrated with your IDE or similar, and have the same versions of your libraries available that your application uses).

> Why? Your system is (or should be) a single-purpose tool.

Stability. My assumption is that one would be using their workstation for tasks much broader than the production environment: development, debugging, slideshows, video conferencing, screen recording, etc. Without execution boundaries, it's almost inevitable that there will be incompatibilities.

Stability of the prod software may be impacted, when something on dev environment (and only on a specific dev environment) because the engineer added an implicit dependency on some aspect of their environment inadvertently.

It's a tradeoff to be sure, but IMO if you're a developer then development and especially debugging should be the priority. I've worked at one place where developers had a second "office machine" that we used via RDP for doing emails/presentation/etc., kind of an inversion of the usual suggestion of setting up your main system with a stable environment and using a VM to match your deployment environment. I found that way more productive, because using a remote or VM imposes much less overhead on everyday office stuff than it does on debugging where you want to be able to connect your IDE to the running process, add packet filters to your kernel or whatever. But I guess YMMV.