> Are these worth sacrificing control over your editor config?
You're not sacrificing any control. I'll speak only of the ones I know: vundle, neobundle, and vim-plug are using very basic Vim mechanisms to save you the hassle. Appending to &runtimepath is the Vim equivalent of modifying your shell $PATH.
And deferred loading, if you choose to use it (I don't), actually gives you more control over plugin behavior.
> You own your vimfiles
This is emacs mentality. I don't want to own (read: maintain) the plugins I use. If I find a bug, I send a PR upstream so others can benefit. If the bug is unforgivable I uninstall the plugin. (You can also pin to a specific SHA).
I think that plugin managers (further complexity in editor configuration) are Emacs mentality. See, ELPA. The approach I'm describing is how people maintained their vimfiles before plugin managers became popular.
New Vim users are told to use a plugin manager now if they want to install other users' scripts, and I believe that is a flawed approach to configuring a lightweight editor like Vim.
You couldn't be more wrong. Maybe if you have 4 plugins this is a workable strategy. What if you have 20 or 50. How on earth do you update any of them cleanly?
It's because of comments like this that I've reserved my opinion about Vim script managers, of all things, for many years. There's no "right" or "wrong," I favor a tightly integrated editor setup where I own my plugins. Further, I don't believe that reaching for a plugin every time you have a problem to solve is the best or only way to extend your editor. My .vim probably has 10-30 third-party script collections, but "upgrade all vim scripts" isn't something I've ever wished to do at the same time. I prefer to upgrade plugins that I know to be active projects after reviewing the changelog, and I do this about once a year.
Is it so hard to relate to the desire simplicity and control in editor config? It's one place where I want to keep the cognitive overhead as low as possible: No forking git repositories to fix a bug in somebody's indent script that's not been maintained since 2007.
You're not sacrificing any control. I'll speak only of the ones I know: vundle, neobundle, and vim-plug are using very basic Vim mechanisms to save you the hassle. Appending to &runtimepath is the Vim equivalent of modifying your shell $PATH.
And deferred loading, if you choose to use it (I don't), actually gives you more control over plugin behavior.
> You own your vimfiles
This is emacs mentality. I don't want to own (read: maintain) the plugins I use. If I find a bug, I send a PR upstream so others can benefit. If the bug is unforgivable I uninstall the plugin. (You can also pin to a specific SHA).