But when it comes to the aspect of managing updates, project specific installs are better.
And when it comes to security then the answer for both installed and project tool-chains is: Sandboxing.
- run your toolchain in a container
- run your IDE in a different container
- run hardly trusted tools in another container
- use reasonable phishing proof 2FA (i.e. FIDO2) for authentication, use authentication tokens.
This applies to "normal" applications, too. They also should run in their own container. Just because it has an installer or is signed by a company or is on a app store doesn't mean it's trustable.
Thats one of the things phones at least somewhat got right, their apps are containerized by default (through they might give too much permissions to apps but that's a different problem)
Furthermore if possible stand alone tooling which tend to not be very version sensitive can be nice to not include: E.g. git, npm, rustup, pip and similar are preferable system installations.
Furthermore frameworks and similar tend to go through the package manager and whatever update handling you have for it. But a drop in IDE likely would not.
The approach normally doesn't count project local tools which don't install like normal applications. E.g. some frameworks you install into your project instead of having user or system wide installations (e.g. with npm for web-dev stuff).
I know that for embedding computing a lot of tools which are normally ad-hoc project installations are instead system wide "normally installed programs".
But that isn't the case for most software development fields. In many other fields that new tool-chain you want to try out is just a dependency you add to your projects dependency management tool. And keeping it up to date is done in the same way you keep your other dependencies up to date (e.g. a scheduled CI job checking for updates).
Rootless OCI (docker) containers can help with that. But embedding also often touches on driver aspects so it might not be an option.
Anyway if you ignore embedding programming, parts of system programming (e.g. linux kernel), some legacy software and some cases of important C/C++ tools needing too many permissions nearly all other programming jobs should be viable on a locked down system as long as you have the right not too big set of tools preinstalled and access to rootless containers (independent of weather they run in a VM or not).
EDIT: formulations, for clearity