Subtrees interact with history in a much more obvious, configurable, and automatic way. The most obvious win is never having to run `git submodule update`. The better control over history is the bigger, but less obvious win. Since you have some experience using submodules for your .vim, maybe try switching to subtrees and see what you think. I like the Atlassian blog post[0] about them for getting started.
[0]: http://blogs.atlassian.com/2013/05/alternatives-to-git-submo...
For me the the most obvious win is still being able to merge, move forward in time, move backward in time, rebase, etc. Everything that makes Git great.
Once you have submodules in your repo, all that becomes heinous. PLUS everything you mentioned...
Sure, if you don't use those features, then submodules would probably work fine. But then why not just use Dropbox?
Yep, I think a good way to put it is that subtrees are (or feel like) far more "first class" - you can do all the normal stuff with them.
I used to do this for my .emacs files and modules. It worked quite well, but in the end package.el made it unnecessary. Since then I came to the conclusion that git submodules are not a real substitute for a package manager.
Re:Git 2.0 release notes
by bostonvaulter2 on Wednesday March 12, 2014 @07:29AM
(#7384981)
And for vim vundle makes this unecessary.
I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules.
I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning them inside your .vim.
I look forward to having the opportunity to use subtrees.