I agree with the "development tool" ambiguity. I've heard a lot of reasons for IT not wanting to support R. Usually it boils down to IT not knowing it and don't want to spend time learning it. I know that's a pretty harsh statement but that's been my personal experience. This "development tool" reason is a new one for me.
If it's an R Studio issue, then you can use most generic IDEs to code R and run R in terminal or the default GUI (the pre-R-Studio days).
If it's an R issue, then you may have to go over their heads. Some talking points.
- hrs needed to redo all your work in their acceptable language
- hrs needed to retrain or learn a new tool
- successful deployments by large enterprises using R
- as @mishabalyasin, the ability to do your job. they were aware of your skills before hiring.
I doubt this will work for IT but executives will probably be more receptive to these points.
Getting more details about security issue will help. They'll probably be annoyed but you need to understand their specific reasons. Their current reasons are ambiguous for part a) and wrong for part b). Some common specific reasons I've heard in the past.
- R has no LTS, like Node.js
- Packages are not vetted
- Find me docker/chef/puppet scripts to deploy R and install packages for me
- dependency management is not as clean as python or Node
Sometimes there's a misunderstanding of what you are trying to do with R. Many people imagine outward-facing apps built entirely in R so that R is doing all the web traffic and data roles. In this case, there aren't as many tools in the R community to do this securely. However, rarely would a data scientist create that in R. Most likely they'll be creating something only available internally with nothing outward-facing. you can use a Node/express of Python/flask to handle the web security stuff and call an R internal service.