There are two assumptions I think you're making here:

Assumption 1: You can do better than the defaults enough to justify the costs of optimizing. I use a pretty much default vim configuration as my primary development environment, and see zero evidence that this hampers my productivity in any way.

Built-in file searches are good enough for open files, and grep/git grep do well enough for other files.

Linting should be part of your build process. There's a benefit to it being a bit painful for linting to fail, because that negative reinforcement causes you learn the linting rules and start writing pre-linted code.

You might disagree with me that these benefits are minor, but that's only looking at the benefits: let's look at the costs of "optimization":

First, there's the bugs in plugins and bad interactions between plugins. Very few plugins are written to any sort of reasonable QA standard. I've pair programmed with a lot of devs who use highly custom vims, and without fail, they've got bugs in their configurations that are far more distracting and impeding than any minor inefficiencies in the default configuration. Say what you want about the default configurations, but I've not found any bugs in them in years of using them.

There's also simply the time spent configuring. At one time in my life, I spent hours trying to get things just right in my configs. The results were pretty mixed--a lot of times I ended up not liking the changes I had made and reverting them.

There's a bit of hubris involved in believing you can do better than the defaults. Instead of looking at the settings as the problem, consider the possibility that your knowledge is the problem. It's likely that there's a good enough way to solve your problem in the defaults, and you simply don't know or grok it yet.

When I first started learning vim, I thought it was kind of stupid--everything seemed way harder than it needed to be. But once I actually grokked the tool, I realized that my initial impressions were the stupid ones. A lot of problems I've run into over the years with vim are like that--the problem wasn't that the default vim didn't solve my problem, it was that I didn't grok the solution which was easily assemble-able from the vim skills I already had.

A programmer I really respect has a background process which watches file edits, internet usage, and a few other things (i.e. VLC) and automatically tracks his productivity. His process marks time spent editing Emacs configuration as wasted time, and I agree. Although that might be because it's Emacs configs rather than Vim configs. ;)

Assumption 2: Text entry is a significant bottleneck compared to other areas of your process. In backpacking, there's a saying, "Don't save ounces when you can save pounds." The idea is, don't optimize the weight of your lightest things, i.e. your stove and water bottle, when there are still big optimizations to be made on your heavier stuff, i.e. your big three (backpack, sleeping bag, tent). Configuring your editor is almost always an attempt to save milligrams.

Frankly, once you reach a certain proficiency with an editor that's automatic enough to just get out of your way, editing becomes a subconscious process, and you can be thinking about other things while you edit. I think some people believe that they think of what to write, and then edit it in, and any slowness in editing is preventing them from thinking of what to write after that. I don't think that's how the brain works--if you don't have to think about editing, then you don't have to finish editing to be thinking about the next thing. So the best thing your editor can do for you is to not make you think about it consciously. The more complicated you make your editor, the less likely this is to happen. The power of vim is that it lowers a lot of more complex edits to the subconscious level: swapping two lines is three keystrokes, so it's a simple enough process that I don't have to think about it.

Once you reach a certain level of subconscious-ness with an editor, editing simply isn't the bottleneck. I've known Notepad++ users who were faster Ruby programmers than me--I could certainly edit faster with vim, but they could come up with the solution to the problem in their head faster because they're more proficient with idiomatic Ruby. If editing really is the bottleneck, the problems you're solving are quite easy for you, and you could probably get paid a lot more if you took on harder problems!

And that's just looking at the process of implementing features! There's a lot more to software development. I've yet to work at a workplace where requirements gathering and keeping shareholders informed weren't much larger opportunities for optimization than my editor configuration.