My ability to put 'latex manuscript.tex' and 'dvi2pdf manuscript.dvi' into a makefile is not magic, it is basic automation
It's also redundant and likely not to do the right thing (ironic, given previous comments about libraries). Look for latexmk, which is part of the standard LeXLive distribution. Oh, and since this is not 1970 anymore, let's skip the DVI step and go straight to PDF with pdflatex (latexmk -pdf manuscript.tex is probably what you actually want).
The biggest is that you have to think about what parts of the project you might want to check out individually before you start. For new (small) projects, it's sometimes easy, but typically projects grow organically and parts get factored out. There's no good way of turning a subtree in a git repo into a new repo preserving history (and no way at all that allows you to merge into both).
The second big one is that you lose atomic commits (the thing we all switched to svn from cvs for in the first place). If you only have one layer of submodules, it's quite nice because committing something to the submodule and updating the version of the submodule are independent. That means that you can make changes to a component, unit test them, commit, and then later update their consumers. Unfortunately, there's no way of atomically updating two independent subtrees simultaneously.
The third annoyance is the most embarrassing for a DVCS: the remote repository for upstream is identified by an absolute URL. You can do relative URLs, but they don't work very well, which means that if you want people to use a local version then it's quite convoluted. There's no simple 'clone this repo and all of the submodules in such a way that someone else can clone my copy and it all work sensibly'.
In general, the dire UI of git has been an unexpected advantage. No one can stand working with it, so people have been motivated to write nice GUIs that make it tolerable.
Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian