That's a little harsh, but the cognitive bias you're describing certainly is a common one, and it's one I struggled with a lot when I was younger. I've learned to manage feelings of fear or anxiety by reinterpreting their activated, buzzy feeling as excitement or anticipation. This works well, though it has turned me into something of a daredevil...
I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.
I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.
I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.
I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.
Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.
I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.
1 - http://www.github.com/marssaxman/ozette/