Not counting the issues of submodule support by services that interact directly with Git repos, I think the big question is how often do you need to hit the upstream repo for pulls/pushes. If the answer is "not super often", subtree is probably lower maintenance. I think submodules are a little bit more natural in cases when you are making a lot of changes to the subrepo, particularly when it's more standalone. But even then, subtree is probably worth the extra bit of effort.
Actually, in cases when the coupling is very loose, I forgo both options and just check out the subrepo directly into the superrepo, and rely on .gitignore in the superrepo to keep them seperated.
At the end of the day, I think there really needs to be another strategy, and it would be great if there were a way it could be implemented in to the Git core. The concept of a modular project just doesn't seem to completely jive with the Git architecture. Anyone have any ideas how this could work?