That sounds like a horrible work environment. Seriously, devs can't choose their favorite tools, or specifically use tools which improve their quality until IT approves it?
I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.
Would you really want every developer installing their favourite tools/libs and having a complete free-for-all when you've got 200+ devs, each with their own opinions and preferences?
IT have to support this stuff, they don't want to be rebuilding the software stack every six months or so.
This is not about a tool to provides a syntax, or makes commits. It's a tool that runs an instrumented version, only on the location the dev specifies, and reports actual bugs. If your team has a difference of opinion on whether you should fix actual bugs, you have larger problems.
That said, if your program only feasibly runs in a shared QA/dev environment, then yes, it can be understandable to prevent devs installing random tools and utilities there. But in that case, the problem is not so much hedonistic developers, but a lack of separating portions of the code base into individually testable components. Again, you probably have larger problems than whether your devs can install their own tooling (because it's of limited use in a lot of cases anyway).
To be clear, there are good reasons for restricting certain classes of tooling. You don't want the absent minded dev installing some cloud based source code integration tool. Then again, the only way to really protect against this is to isolate the dev network, and not allow internet access. I imagine the loss in productivity is fairly great. I'm sure there's a happy (or not!) medium in there, individual to most companies.
I've worked in bad places where it was hard to upgrade to the latest version of a language, but at least that was always under full control of the Dev group.