Seriously?
What is the advantage of using your cognitive capabilities to write Ommffffy`m^[0"wDdd rather than use a sensible IDE with common refactoring capabilities that are also context aware and integrated with the language you are using?
With practice, it's more like finger memory than cognitive load. What he's doing is setting a mark named "m", going to the second "f", and yanking from there back to the mark. It's a fairly interactive sequence as you move the cursor around, so while it looks scary in print, in practice it's just a series of actions you don't think about much.
An advantage to using commands like this is that you can record them into macros with just a couple extra keystrokes as you go. I used to do a lot of SQL and I'd get bored and frustrated, until I learned to use macros in vim to automate the repetitive parts.
Compared to IDEs, why not both? For languages with good IDEs I tend to use them with vim emulators.
In other programming I don't have particular favorite macros, but still find small repetitive bits here and there that can be turned into temporary macros. Say for example you have ten variables that each need to be reset to zero. Don't type all the resets, just type the variables, turn one of them into a reset while you're recording into macro w, then type 9@w to do the rest.
Copying up to the second f is just a silly example. It could maybe occur though if you were manipulating lines in a data file. You look at it, see that on each line you want to do something with everything up to the second f, so you make a macro. You don't save it for general use.
In short, macros aren't for major repetition that should be factored out, they're for the minor repetitive edits which, if you're not using vim, you might not even think of as repetitive. Sometimes they're useful for refactoring.
So no, I'm not using macros "without even thinking" and this would probably be a more productive discussion if you didn't make such assumptions.
Ah, but you can just name your indexes, so it's a[salary]. But now you've got ten lines of code naming each of the index values, and a vim macro makes it faster to write again.
In any case, macros are just one of the features that make vim productive. I find that I do a lot more small refactors when I'm using an editor that makes arbitrary edits really fast and convenient. It's complementary to the named refactorings you have in an IDE. If all you're doing is pointing and clicking then you don't need vim, but if you're actually writing code, it helps.
I used to use a vim emulator in Visual Studio, and it was great. Now I'm working with stuff that doesn't have IDE support, and I'm still productive.
A lot of good programmers are hooked on vim. Hasn't it occurred to you that maybe they have good reasons for that?
employee = new Employee();
I guess I'm failing to make the point, so I'll just refer to the articles that got me to try it in the first place.
While remembering long button combinations seems hard and tedious and "strain on cognitive capabilites" they really are just chained commands. In the idea world you don't think: "now I just have to hit v4w"+y to copy these things to clip board", but instead: "I'll copy next four words into clip board" and then just execute the commands. Same goes to longer commands, instead of hunting down some hidden feature in your IDE, you can just bang out chain of commands you wish to execute.
AKA a function.
> code editor is to be context aware and transform your code accordingly to the language rules, not just blindingly execute a series of commands
If you "blindingly" execute a series of commands in anything, it's not going to end well. Also, vim can load commands/plugins based on filetype, or any arbitrary condition you want.