Godzil > -fonctionnel +procédural

Sinon, pour rajouter une couche au débat… De manière générale le code est bien plus facile à tester quand une fonction/méthode ne dépend d'aucun paramètre extérieur à la dite fonction (ou le type déclarant la méthode).
C'est aussi assez cool de pouvoir se dire qu'on peut faire tourner deux instances de la même application dans un seul processus sans jamais avoir le moindre problème. Bien sûr, ça n'arrive en général jamais. (de devoir faire tourner N instances par process)

Par contre, ça n'exclut pas d'utiliser des variables globales dans les cas où ça se justifie…
Par exemple pour implémenter des singletons d'objets immutables / stateless qui ont de l'utilité partout dans le code. (C'est pas intéressant de prévoir de demander une référence d'objet en paramètre pour du code dont on sait déjà par avance qu'il ne changera jamais)
Par exemple parce qu'on estime qu'un objet/concept a réellement un rôle clé dans le programme et n'est voué qu'à exister de manière unique. (C'est par exemple le cas du ThreadPool en .NET. Ça ne viendrait à l'idée de personne d'en vouloir plusieurs. C'est pas fait pour, et ça marcherait mal)

Le problème se posera plutôt dans le cas d'un objet dont le contexte n'est pas neutre. (C'est en général le cas de tout ce qui a un état interne)
Typiquement, pour l'objet qui va servir à effectuer les opérations graphiques dans un jeu/autre, on sait bien qu'il n'y en aura jamais deux, car ça n'a aucun sens. Mais malgré tout, l'objet porte un état précis et a une interaction forte avec le reste du programme (même si cette interaction est surtout unidirectionnelle). Dans ce cas, ça peut vraiment poser problème si deux morceaux très éloignés du code référencent ce même objet, sans coordination entre l'un et l'autre. (Peut-être que le programme peut crasher à cause de ça ? Qui sait…)

En tout cas, je ne jugerai pas sur un petit projet. Variable globale ou pas, c'est surtout une question de discipline. Par contre sur un gros projet où plusieurs personnes doivent bosser, la question n'est pas à poser.