I work somewhat similarish to you (or at least, closer to you than the environment suggested in the OP), but I really don't understand why you're so disturbed. Don't use tools you don't want to use.
In one company, the primary language was Scala, and one of the primary Emacs tools for Scala is Ensime. But the company had its own bizarrely wrapped version of sbt running inside of pants tasks, so without explicit support from IT, it was not possible for a developer to use Emacs+Ensime for that Scala codebase.
I am perfectly happy for people who use these UI-heavy tools productively. But the marketing shtick attempts to raise it in popularity and promote it, like this very paper’s recommendation, seem harmful to me.
Code tooling should be extremely fractured, bespoke and customized, by its very nature, and that should be embraced and supported. Instead it seems like PR battles and a rise of (IMO) ineffective proprietary tooling.
Why? That sounds like it would make things more expensive and harder to learn.
I think your reasoning is completely backwards on this: it’s not expensive to support many different sets of tooling. No, what’s expensive is paying a lot of money for people who can be very productive for you, but then preventing them from giving you that productivity due to poor tooling. When the poor tooling has been standardized, your good developers are heading to the exits.
I flip back and forth between "working the big, working in the small" (paraphrasing Bill Joy). Sometimes closer to the metal is best. Other times I prefer the IDE with all its conveniences.
But I am the first to admit that sometimes I do get trapped by the IDE, distracted by fighting the tool instead of solving the real problem, and have to take a step back.
Said another way:
I only really object to IDEs and other tools of convenience when they hide the metal.
Like when you have the wrong mental model for a problem, and you're fighting the model, instead of finding a better model.