Not if you're separating where you live from where you work - in a manner of speaking. 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). Debian stable provides a good workstation environment - the actual work should not be done against Debian-blessed packages. The opposite is true - your workstation packages should not be dictated by the needs of your prod software.
> 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).
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.
For my development needs I prefer Debian Stable and install the dev tools locally in my home directory rather than using the packaged versions.
Since I don't share those boxes, it works well for me. I keep up with the frequent Android Studio / VSCode updates that way.
At that point you end up manually doing the job of a package manager.
For better or for worse, I think this is partly where my preference to use rbenv, pyenv, asdf, etc comes from.
The other part was from hosing my system installed pip packages for the Nth time because long ago I didn't fully understand pip (still don't, but I didn't then either) and I used a mix of "pip install" and "sudo pip install" when the former didn't work. I could only work on one thing at a time with this approach, and switching was a huge task because I had to figure out all the places where packages had landed and either remove them individually or blow the whole thing away.
(And, as another reply mentioned, you'll miss out on a lot of usability improvements to development tools by running stuff that's 2 years old or more)
> For things not in the Debian Stable we're using, such as if we need a bleeding-edge version of some key thing, and we have big security/reliability requirements... I manage non-Debian-packaged third-party dependencies in our own Git repo, and track and vet updates. This also means trying to minimize these dependencies, more than we would if we were pulling in 100 packages casually from a language-specific package manager, since each package is additional work.
Making it harder to have up-to-date dependencies is costing you far more than you're saving by not upgrading frequently.