You don't need Emacs or Vim to be an incredibly successful software engineer. It's actually the opposite, Emacs and Vim users are a minority among successful software engineers.
So they are only a specific kind of power tool.
More than that, they can't even handle the "ridiculously complicated". Common examples are trying to use them with projects containing millions of lines of Java or C# code.
But using a more advanced editor can make it easier. If you are going to be doing software engineering for a few decades all the times you have to do some repetitive task in a simple editor that would have been quicker in a more powerful editor adds up.
I'm arguing that IntelliJ/Visual Studio are more powerful than Emacs or Vim.
The Emacs and Vim architectures are antiquated and the volume of effort put into developing them (and their ecosystems) are outclassed by modern IDEs, especially for languages that scale to large numbers of developers working together (Java, C#). Emacs and Vim are poor man's IDEs compared to actual IDEs for these cases.
Emacs and Vim are mostly popular amongst C/C++ developers, where the ecosystems are generally baroque, forced by the need to integrate with embedded systems with limited toolchains or with libraries/frameworks that are very limited, and amongst developers working with dynamic languages, where you generally have small teams. Or large teams and a ton of headaches :-)
However, that in itself is not my reason for preferring Emacs. It's also my markdown editor, often my file manager, my PDF viewer, my image viewer, my git interface, IRC client, email client... I could go on, but I'll stop there.
Emacs is not and has never been an IDE, it's a highly versatile and extensible text-editor. You can't compare apples and oranges.
Outclassed in what way?
Have you looked at LSP[1] and its support in Emacs[2], for instance?
That's not to mention things like SLIME and paredit for Lispy languages, or the integration of the rest of the Emacs ecosystem in to your development environment, the ability to develop and configure all these development tools in Lisp instead of being forced to switch to some other language, etc.
[1] - https://github.com/Microsoft/language-server-protocol/
This is not surprising; it's no different from Vim users who have never written or debugged a line of VimScript.
Donald Knuth. Author of "the art of computer programming" and many contributions in computer science.
Linus Torvalds. Original author of Linux (the most widely used kernel) & git (most widely distributed version control). In fact, he wrote his own version of emacs. He doesn't do much, if at all, coding now.
Joe Armstrong. Author of Erlang.
Guido van Rossum. Author of Python.
Yukihiro Matsumoto. Author of Ruby.
Rich Hickey. Author of Clojure.
Andrei Alexandrescu. Author of D.
Xavier Leroy. Author of OCaml.
Michael Widenius. Author of MySQL & MariaDB.
Guy Steele. Co-author of Scheme.
Stephen Wolfram. Physicist, computer scientist & author of Mathematica.
Peter Norvig. Research director at Google & well known Lisper.
RMS. Well, original author of GCC, Emacs & the GNU system.
All of them, apparently, don't require one of those "powerful" IDEs.
VSCode would need to be 10x better for the seasoned veterans to justify switching. If it were only 2x better, arguably the investment would not be worth it, but it doesn't change the fact that VSCode would be 2x better than emacs.
At the end of the day, it's kind of just shifting around based on what feels good. It feels similar to sitting in a cafe for a bit, but some times working from home, and some times in the mountains.
But there's no need to put people down by saying stuff like "poor man's" IMO. And if you're restricted to what makes C# and Java tolerable, that's a small space. There's a lot more stuff out there.
And programming is not as simple as "make decisions that optimize your engineering throughput" IMO. Otherwise gardening would be agriculture, right? Both are important in their own ways.
In any case Vim's terminal emulation and asyncness these days along with coc.nvim brings it back on track IMO. There was a period where it was behind.
I do think it depends a ton on language. The best experience in Vim is editing Go, I think. And then TS and C++ have been a close second. Lisps are not great, Emacs tends to better. For Java and C# it's definitely IDEs. VSCode is also fine for a lot of langs, in a more out of the box way. Cursive is also good I hear for Clojures. If you need to move between a lot of langs, the only IDEs that pan out are IntelliJ mostly, unless you count Code as one. But Vim and Emacs have the best multiwindow and multi buffer management. And the best git integration for patch by patch staging, for sure.
And ofc for ObjC and Swift it tends to be Xcode. If you're really into Freepascal then Lazarus etc. Smalltalks are their own thing ... it keeps going on.
The name "Microsoft Visual Studio" refers to a product line with a long life, which had been a monumental piece of shit over most of that life.
Vim and Emacs helped people survive Windows development jobs centered around Visual Studio.
For a lot of tools, both in software and other fields, there are three different classes of user.
1. Those with fairly straightforward tasks that they just want to get done.
2. Those who mostly have staightforward tasks, but occasionally have something a bit more complex but not too complex.
3. Those that need to handle everything from simple to ridiculously complicated.
Take electrical testing tools for example. For a lot of people a simple battery tester is all they need (class #1). If you want to test a battery and have never used a battery tester before, it will either be obvious what to do, or a glance at the instructions will tell you.
Some people need a bit more on occasion, and for them we have a class #2 tool, the multimeter [1]. You can still pretty easily test a battery with one, but the first time you probably will have to spend a minute or two in the manual, learning what voltage setting you want (the V with the ~ over it, or the V with the dashed and non-dashed line over it?) and which holes to plug the probes into.
Some people need a lot more. They have a class #3 tool, the oscilloscope [2]. You can check a battery with an oscilloscope, but if it is your first time you are going to spend a lot of time in the manual before you get there.
Emacs and Vim are class #3 tools.
[1] https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87...
[2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-O...