I will preface everything with: if you don't see yourself getting value out of vim... don't use it. It's that simple. Vim has been one of the greatest things in my life for most of my life, but that doesn't mean it will be for you. Everybody is different.
Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.
I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.
First the technical implementation
Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.
To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.
Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.
A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:
au BufNewFile,BufRead Jenkinsfile setf groovy
None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]
Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.
Getting a bit more philosophical
If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.
In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.
The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].
The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.
Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.
[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.
[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.
[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".
[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.
Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.
I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.
First the technical implementation
Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.
To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.
Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.
A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:
au BufNewFile,BufRead Jenkinsfile setf groovy
None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]
Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.
Getting a bit more philosophical
If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.
In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.
The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].
The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.
Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.
[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.
[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.
[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".
[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.