Because I don't need them, and would rather focus my attention on the part of the job I actually care about. The simplest tool which doesn't waste my time is the best. I have found that I would rather use a simple editor with no features that I never have to think about, and automate repetitive tasks using the same tools I already use for automating repetitive tasks: programming languages.
That just sounds like a self rationalization to me. "I don't need them" is something you say after you tried something and realized you actually don't need them. It doesn't carry any weight when you haven't even tried. Because when you do, it's just saying you don't want to try new things. I'm not saying you must learn these, I'm just saying you shouldn't lie to yourself.
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.
So... you'd rather spend the time writing new code to do repetitive tasks rather than use existing ones? You'd rather spend time writing 'search and replace' in your favourite language than just use an editor with it? I don't see how that doesn't waste your time.
I'm happy to spend a little extra time every now and then doing some unusual task by hand in exchange for never having to think about the editor or try to remember how some powerful, infrequently-used feature works. As long as the editor can do everything I want to do on a daily basis, I'm happy; if it can also automate tasks I only have to do every week or two or every couple of months, it's a waste, because it'll take some effort to remember that the feature exists, what it's called, where to find it, and how to use it. I'd rather just use a simpler editor and deal with that oddball task in whatever way is convenient when it comes up. Since I spend all day slinging code, bashing up a little script to do some odd code-munging job is no trouble; I already have all the tools I need to do that paged into my working memory.
I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.
