> Their argument is that all team members should use the same tools, and I guess that is a valid point.
Why is that a valid point?
In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do.
For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".
In my personal life, I still exclusively use emacs (which I have scripted to auto-detect venvs) but I put up with using vscode at work to be a greater utility to my team.
It's just less effort all round to have everybody using the same supported set of tools. I don't know if I've ever worked on a project that's gone so far as to actually mandate this, but a "should" (possibly in the RFC sense) is fair enough I think. Every project I've worked on has ended up with everybody eventually settling on using the same tools, because it's just overall less hassle that way.
(Regarding Emacs, I'm typically using it anyway for org-mode, so if I need to do some one-off edit or other - probably some keyboard macro thing - then I can just load the problem file into Emacs and save it back out again afterwards. I've only once been in the situation of neither being allowed to install it nor remotely connect to another machine to use it.)