Well, i am pretty sure passing some refs/pointers all around the code base just because somewhere deeply in the codebase somebody might want to use it is a bigger antipattern than using singletons...
And if 99 command from 100 don't use it, then i feel like it's unnecessary.
And making a global variable so 1 command out of 100 can access it is... better?
I generally agree with the others who don't like global variables. However, this sometimes results in making "Manager" classes, especially when I cannot think of a better name. After all, everything that is not global has to live somewhere else. I don't really feel like having 50 objects sitting at the bottom of my call stack. To organize them into something more manageable, all of these non-global objects have to be packed together into other objects, which may or may not be "managers". I try to avoid the typical ugliness of a manager by keeping all of the real work in the owned classes instead of the top-level class.
So, if a generic Command class needs to be able to mess with anything in the whole world, maybe you have a "World" object that could be passed into it. With just a World object, you might be able to change any gameplay stuff around, but things like the current user input state or a sound player or any rendering commands would be inaccessible. At least you've partially restricted what a Command can do. If the sound player or rendering or user input were just global variables, there's nothing stopping a Command from touching them. At least with parameters, your intent is clear for what a function is supposed to be able to effect.
If some function is supposed to be able to do absolutely anything to the whole game, and every top-level game class is passed into it, at least it's clear that the function can do anything. You might call it an "antipattern", but changing parameters into global variables doesn't solve the problem apparent with the antipattern. It just hides it. Every global variable is already an implied parameter to everything.