1. I don't really want to bother with a DSL for configuring my editor (even if the language is usable outside of that context for other things)
2. I don't have time to bother with maintaining extensive configuration to get the level of code completion/refactoring/etc that I expect from a modern IDE (nor do I want to have to stop what I'm trying to work on to debug a problem with my config)
3. I don't want to have to research various plugins and stuff to provide functionality that I get out of the box with VS Code (or other editors)
4. I don't want to have a bespoke environment that only I understand when I'm trying to collaborate with my teammates
Don't get me wrong: I think digging into emacs and/or (neo)vim is a valuable thing to do and that everybody probably *should* do it at some point (even if only as an academic exercise), but to assert that they are a viable path for everyone is ignoring the reality that some people simply aren't interested in investing that time/effort into getting their tools working.
One can argue whether or not that stance is a good one or not, but you're just debating personal preferences and priorities at that point.
On the contrary, the article said, literally: ”We are primarily a Go and Python shop, which means our only real option is VSCode”. Meaning they do not consider Emacs to be a ”real” option. This is expressing more than mere personal preference; it is, at best, profound ignorance of what Emacs is capable of.
It's unlikely that a given team/workplace is going to roll out dev tooling that is just a pile of elisp. With VS Code, you can drop a couple of JSON files into your project, commit and push them, and then everyone has a preconfigured set of tools that match the needs of that project.
