Vim is "the ubiquitous text editor" that comes preinstalled on most Linux, UNIX, and other UNIX-like systems. Having evolved from the older Vi, it is one of the belligerents in the "editor wars" against Emacs; Both programs have a large userbase among those who do a lot of system administration in part because they are designed to work really well in a terminal. As most sysadmin work is done in a terminal, a text editor that one can easily drop into from the terminal feels like a natural fit. What helps to make these programs more appealing to prospective users is that they both have a reputation for speed—in the sense of running quickly as well as enabling users to work faster.
When taking my UNIX Operating System class during my undergraduate degree, the class' professor used Vim for all demonstrations. He noted that it was a challenging editor to learn but that it'd be worth it due to the increased speed that came with it. The professor—who was also the instructor for all other second-year comp sci courses during that term—then challenged the class to do their entire term in Linux, because he knew it'd be possible.
Unfortunately for me, challenge is seldom a deterrent.
I proceeded to then learn how to use Vim, and did my entire fall term in Linux with it as my main editor. Then, I did the next term in Vim. Soon enough, I was doing everything in Vim—programming assignments, non-compsci writing assignments using PDF rendering tools, you name it.
After 8 years, I stopped using Vim. I don't even use anything approaching Vim anymore—my preferred text editor is one which I wrote myself and which is in many ways the opposite of Vim.
Vim as an editor has a reputation for enabling speedy writing. It is navigated using the keyboard, though not how one might naïvely assume. Instead of using arrow keys to navigate within between lines, you use the keyboard's letter keys like so:
Entering a number before any of these motion keys will duplicate that motion by the given amount, so typing in 10j would cause the cursor to descend by 10 lines. To enter text, there are some letter commands that will enable various edit modes. Once in edit mode, text is entered verbatim as typed in the keyboard. The escape key will exit an edit mode and return to "normal" mode where keyboard-oriented navigation can resume.
Vim has many more motions than what I've discussed. There are motions to move paragraph-wise, to jump to specific numbered lines, to the next instance of a certain character, you name it. A seasoned Vimmer can easily navigate to whatever part of the screen they want without much thought by simply typing the right combination of keys.
Of course, the same can be done using the mouse as well. As a bonus, the mouse is smooth and comes with a scroll wheel to quickly scroll a view's content in a way that is easier and more legible than mashing scroll keys again and again. A mouse's sensitivity can also be increased such that less movement is required on the user's part.
My personal understanding on the matter of using a mouse pointer to select text or move a cursor—based on the limited hard evidence that exists—is that it's probably faster than using the keyboard to navigate, even if said keyboard navigation is very featureful and optimized for speed. I'm probably not going to be able to convince you of that though, but the argument I'll share doesn't actually depend on that.
The fact is that text editor choice doesn't make a difference for the most common use-case for a text editor, which is to write something new. Generally, entering new text into a text editor or similar computer widget is going to be the same experience; Characters are typed verbatim to construct the text that the user is writing. There's not a lot of variance to be had in this use-case.
Still, entering new text is not the act which Vim has supposedly optimized—it's editing existing text. Being able to quickly fly around in a text file or in program source code certainly seems like a worthwhile thing to learn, but ultimately it wouldn't matter if Vim actually delivered on its promises of enabling the user to quickly navigate through a file because navigation and tiny edits are never the bottleneck when writing or programming. The bottleneck is in thinking; Thinking about what needs to be done, how a fragment may need to be reworded, whether the whole makes sense, if something was forgotten. Speeding up the time it takes to make small changes only makes sense if that's slowing you down, but I have never felt slowed down by this specific kind of task.
Even assuming that one can meaningfully save time on small text editing tasks by using a program like Vim, it would be on the order of at most of a few minutes per day. I'll be generous—if using Vim saved you 15 minutes per day, what else could you fit in that time? If you're a programmer, the answer is: nothing. If you're a writer, the answer is: probably nothing. Both of these tasks are heavily dependent on high-focus states of mind in order to produce artifacts of meaningful scope; Getting into the mindspace to write or program anything substantial requires far more than 15 minutes. This is why researchers measuring the ways that software developers work found that it takes a bare minimum of 2 hours for a programmer to do anything meaningful. That finding rings true for me as a programmer except when fixing the most trivial of bugs or typos, but that's not really a meaningful accomplishment. Having failed to write many posts on this blog entirely because I couldn't get into the mental space needed to really hammer something out, I suspect that a similar thing is true for writers generally.
Using Vim demands a lot of repetitive movements. Many taps of the H, J, K, L, W, E, B keys and more—hundreds or possibly thousands per day—will eventually lead to repetitive strain injuries. I spent all of this time spent learning, mastering, and suffering through Vim in service of "productivity" gains so marginal as to be effectively meaningless. I quickly abandoned that program once I came to understand both the toll it exacted on me as well as how little I was getting out of it.
I think my life—both as a programmer and as an alleged writer—is better off without Vim. I truly don't think I lost anything of value. If anything, I still strongly suspect that needing to hit so many keys to do anything meaningful in Vim had the effect of tricking me into thinking I had done something of value when usually I had simply fidgeted or messed around. Honestly, I think what's most telling is that I never published any free software back when I used Vim. Most of what I wrote in my free time for myself were tiny little scripts that I don't even use anymore, because they were intended for a mode of computing that I no longer engage with.
All that said, I don't think I regret my time with Vim nor do I think that time was wasted. I learned a lot about the mindset that leads someone to pick up a tool that is probably suboptimal for the problem at hand. I learned that it's easy to optimize for the wrong outcome. I learned enthusiasts will spend innumerable work hours reinventing dismal wheels that get them nowhere without measuring the effectiveness of their solution. I learned that creating more distractions for myself is probably not a great way to stay focused on work. Though I don't think Vim was in any way responsible, I did technically get paid to do programming work using Vim which at least meant that it didn't get in my way when it came to professional work—maybe that's the reason it continues to endure?
Either way, I don't think we should be encouraging new programmers to learn, use, or really even think about Vim. Not worth it.