Can vim and/or emacs do refactoring? That is a feature that I use daily and couldn’t live without

Yes. Well, Emacs definitely can, and I have no doubt Vim can with the same tooling. For example, Emacs has excellent support for LSP. If a language server exists for your favorite language, and it supports refactoring, then so does Emacs.

You’ll find that most of what happens behind the scenes in vscode is available in neovim (and probably vim and emacs). The heavy lifting is done by lsps these days.

One notable exception is that neovim has treesitter, so you get immediate semantic analysis on your code which allows for much more flexible refactoring. Like everything in vim, you need to spend time setting these things up to streamline your common workflows.

Of course, both coc and lsp are your friends there. Want to change variable or function of class name or whatever? No problem. Take this piece of code and wrap it into a function, and where it once stood just place the function call? No problem. Etc.

Note that refactoring only exist for some language: for Java it exists in some IDE, for C++ no.

CLion absolutely has refactoring for C++ (perhaps not as powerful as for Java, but there is plenty).

Worth noting that debuggers, which frequently have complex interfaces, are generally much better suited to GUI applications.

Having a good debugger integrated with my code editor is basically the reason I use an IDE instead of vim. Stuff like Vimspector exist but are way more work to use vs. a GUI equivalent.

The gdb TUI with a simple config and a simple readline config from a terminal has personally done wonders for me. I get vi mode, tab completion, syntax coloring, a colored prompt and really all I could ask for. I have aliased gdb to "gdb - q -ex start --args" and the experience is very nice.

If your debugger implements the DAP protocol then Neovim is currently capable of a just-as-good debugging experience in my opinion.

The sole exception in my opinion is remote debugging (it’s not too bad, but JetBrains really bootstraps this part very well).

I think the interesting thing with debuggers, though, is that I relied heavily on debuggers back when I was relatively new to programming (maybe the first 10-15 years or so), but once I started to feel like I knew what I was doing--and the stuff I was doing became a lot more complicated--debuggers started to feel a lot less useful and even frustrating or limiting... particularly so given that to actually make a debugger work really relies on you buying your entire project into some unified concept of how execution will happen, as the ability to step across IPC/VM/network boundaries is otherwise a pipe dream. I thereby only feel like I get value out of stepping through some code only once every year or two, and gdb is more than good enough; otherwise, I always make sure I have really good mechanisms for logging and error handling, and leave the debuggers for when I'm teaching someone how to code.

This but less insultingly.

Eh, I'm pretty good w/ both gdb and pdb (python's debugger) and whenever confronted with an IDE's debugger (or Firefox/Chrome) I instantly feel like I do when confronted with an IDE: I'm at the mercy of whatever UX this thing will grant me. Scripting will be nonexistent/unfamiliar, specific information will be hard to find, etc.

I have a (maybe overbroad) critique of GUI software which is that it mostly brought us pixel-level graphics at the cost of extremely restrictive UX. Or said a different way, GUI apps look better but they're usually harder to get work done in.

Part of that is toolkits, part of that is you're using a mouse which is like driving a space ship with a single finger, part of it is the expanding user base of computing (to people who don't necessarily want to learn say, regular expressions). But like, I script GDB. If your IDE debugger won't easily let me do that (or it will but it's a painfully convoluted UX), it doesn't really matter to me that it (subjectively) looks nicer.