J'espérais que c'était connu, mais visiblement ce n'est pas le cas, donc j'élabore:

Le GC fait que tu dois fixer un seuil de mémoire arbitraire à partir duquel libérer la mémoire, donc tant que tu es en dessous du seuil, le programme en consomme de plus en plus sans rien libérer, et si tu le dépasses, plus rien ne marche (ça commence à passer tout le temps dans le GC et, si jamais ça sort de la boucle, ça finit avec une exception "Java heap space" ("exhausted", mais ce n'est pas écrit explicitement dans le message de l'exception)). Du coup, tu ne peux pas utiliser de manière efficace la RAM de ta machine: soit tu bouffes toute la RAM pour rien (seuil trop haut), soit le programme plante alors qu'il resterait plein de RAM dans la machine (seuil trop bas).

Un autre gros inconvénient est que le GC bloque l'exécution régulièrement à des endroits difficilement prévisibles, ce qui non seulement rend le Java inutilisable pour toute application temps réel (Ce n'est pas par hasard qu'il y a un gros avertissement de Sun/Oracle de ne jamais utiliser la technologie Java dans un réacteur nucléaire, ce serait le prochain Tchernobyl!), mais se remarque aussi dans la vie courante quand l'interface utilisateurs d'un logiciel freeze soudain pour une seconde ou deux parce que le GC a choisi de s'activer de nulle part.

Et le troisième gros inconvénient est que le GC fait que tu ne contrôles pas quand le finalisateur de l'objet sera appelé. (Du coup, les objets pour lesquels c'est important nécessitent un close() explicit qu'on risque d'oublier, et il y a ce hack de "try with resources" qui fait que finalement, ces objets s'utilisent de la même manière qu'un objet RAII en C++. Sauf que tu ne peux pas oublier d'appeler le destructeur en C++ alors que tu peux oublier d'utiliser "try with resources" ou d'appeler close() explicitement en Java.)