Sure, but "Competent users tend to have preferences" doesn't exclude slow evolution of sane-by-default preferences for programs part of a same class. A newcomer text editor, say, comes in town, settles its default configuration as the sanest of previous generations, while existing programs of the same class are (reasonably!) stuck due to compatibility.
Which means newcomer text editors need less configuration, and users generally staying closer to the default stable, tested configuration.
You can argue that you're part of a margin needing XYZ specific setting, or that new programs don't necessarily make good default config choices. To me it feels generally reasonable to believe so.
Case in point, with text editors / light IDEs. I did Sublime Text -> Atom -> VSCode. At each step, the size of my config size decreased. Of course I still have a VSCode settings.json, but it's twenty lines. My sublime prefs are ~100 lines, my .vimrc is hundreds :)
The plugins you need to make Atom/VSCode great (no experience with modern Sublime) definitely count as configuration in my book, and often come with their own configuration load. If I sit down at a new machine, they won't be there. Most of my .vimrc is a couple of lines per plugin configuring the plugins, for example.
You're going to get a fuzzy file finder, Git integration, syntax highlighting, symbol navigation, and and a package manager immediately available to you in those editors. None of those are available in Vim by default; that's the inspiration for Amp.
There are additional perks to including things by default, too. Jump mode is a good example of that: it's integrated with its select mode. You can start a selection and then switch to jump mode to move the cursor to complete the selection.
Lastly, there's simplicity in including things rather than asking new users to pick from a dizzying array of plug-in options. Rails is a good example of this: there's a lot of functionality that could have been left to 3rd-party gems, but having the framework include them by default means they'll work out of the box, and there's a single canonical solution to [sessions, templates, ORM, routing, etc].
I don't disagree with your approach but I'd just point out, since it's a little ironic, that rust's standard library is a good example of the opposite approach!
I'm going to resist adding everything but the kitchen sink to Amp. Upcoming features like tasks and language server protocol support will allow Amp to integrate with language/framework-specific tools as easily as possible, but without steering Amp towards any specific choices. I couldn't avoid that with syntax highlighting; it's just too essential (and it powers the symbol jump mode). It's definitely a balancing act!
Vim doesn't have syntax highlighting? News to me. Git and file finder is available to you by opening a new terminal tab/window and simply using git/standard unix utils. There's no need to integrate such features when you can extend a terminal into an IDE as your needs suit.
Vim has very simple highlighting, and doesn't support symbol jump; that's why ctags is an external dependency for that behaviour.
As for a file finder, I'm curious how you can use a separate tab to open that in the current instance of Vim? From when I'd last used it, most folks were using Ctrl-P to solve that problem, and usually with an external indexer like fzf or ag.
Which means newcomer text editors need less configuration, and users generally staying closer to the default stable, tested configuration.
You can argue that you're part of a margin needing XYZ specific setting, or that new programs don't necessarily make good default config choices. To me it feels generally reasonable to believe so.
Case in point, with text editors / light IDEs. I did Sublime Text -> Atom -> VSCode. At each step, the size of my config size decreased. Of course I still have a VSCode settings.json, but it's twenty lines. My sublime prefs are ~100 lines, my .vimrc is hundreds :)