If anything the thing that is a killer feature that I always try to get out of emacs but ends up being half baked is the code completion/code aware tools (like the example given of refactoring). With emacs and yasnippet I can emit a ton of code but if I ever have to do a big surgery and have some level of assurance it's right as I go along is nice and I end up falling back into Eclipse/Visual Studio for those sorts of things. I have rarely gotten Emacs to have good code completion with most large software projects, and I end up using tools like opengrok to do the initial search because it just indexes better before diving in with emacs.

Because emacs in most implementations is not project aware the same way an IDE is (like the ways eclipse preprocesses the project and holds a coherent data model in memory while you edit) it just doesn't have the tools available to even build off of. It was only post-LLVM that tools for that kind of formatting and editing are expected to be coming from the compiler's AST itself (things such as https://langserver.org/ is pretty exciting). I think Go has some of the best source code at command line tools, but they are leveraging that there is a 'one true way' of go tools to work that is easy enough to deal with so a simple command can do just enough work to do what needs to be done as opposed to a C/C++ application that is a #define soup with custom build infrastructure that emacs has no way of getting a coherent model out of to decide whether it can refactor things or not.

I keep trying to make emacs work for it, but it turns into a lot of custom tooling that I really don't have time to build for the kinds of applications I end up having to work with. Emacs is still superior for actually reading and writing large bodies of code, just it is awful on operating on the code at a syntax-aware level and doing the same quality of IDE-grade checks to make it a mechanical thing as opposed to a brain-driven thing.