In my view this is not a question of one side being right and the other being wrong 
You can always do versioning. At least I cannot think of a reasonable setup that prohibits it.
For me the real question is actually not a technical one. (Although I am a very technical person.) Instead it is about the business goals that shall be achieved. In that sense I have not yet met an organization that said “we want to slow down our developers”. Because that is what happens with any other setup, compared to a local development environment.
A local development environment has, for the context of this discussion, two main characteristics. First, it is local :-). Local here means that the developer has full control. For me that includes admin rights! Because you always come into a situation that you need to install a certain tool to make your life easier. This dev environment can also run on a VM, so it does not have to be local in a strict sense. The core aspect of local here is easy file system access, because version control by definition happens on the file system.
Second, the developer should be the only person working on that environment. Yes, technically it is possible to share. But there are two huge downsides to that. The bigger one is added complexity, which slows people down greatly. The smaller one, and it is kind-of related to the other, is the increased risk of by mistake interfering with someone else’s work.
I understand that managers shy away from switching to a completely new way of doing things, and I have had similar discussions with customer countless times over the last 15 years or so. What has helped me is to very directly ask what negative aspects people expect from a switch to local development. Then these challenges can be addressed. Because usually people understand that local development creates better results. It is just that change always comes with risks as well. When those risks can be addressed, that is a start.
It is also a possibility to start with just one local development, rather than switching over completely. That contains the risk, allows people to learn the work with a Version Control System, and comes with limited effort. Without additional details it is difficult for me to be more specific. But I think the best results come by finding a way that fits your organization’s business needs and(!) takes into account where you are today. In other words, an approach that looks great on paper, but ignores your current capabilities does not help. The probably biggest factor for success is an honest assessment what needs to be learned. I don’t mean this in a patronizing way at all! Having worked with various VCS I still learn new stuff every day.
I realize that was a rather long answer, and possibly not the one you wanted. But it is my honest opinion and so far has worked great for me.
Hope that helps!
