Perhaps they are minor if there's one or two global variables. Once they're used liberally and there's plenty of them, the resulting bugs can become so elusive it can drive you mad.
A bug can be extremely hard to replicate, because it only arises from a very specific sequence of events that step-by-step flip the globals into an overall invalid state. And it's virtually impossible to determine "whodunnit".
It's a perfect recipe for "the app sometimes crashes on Thursdays" scenario.
Ah, I meant to reply specifically to the command line flags use case.
For most other uses of globals, I fully agree.
Ah, then I misunderstood you, sorry.
Of course this is a bit of a red herring anyway... As the original commenter remarked already, command line flags may be stored globally (eg. as read-only fields), but won't - and shouldn't - be variables.
They're only given once, and their values aren't going to change throughout the program's running time. So they're essentially constants, which is fine.
(A) it makes the code "singleton" by default: you can't instantiate two objects of the same class with two different values for the global argument
(B) unless the global argument is declared in the same class, it slightly obfuscates the fact that a class depends on the argument (compared to all dependencies being constructor parameters)
(C) it makes testing, especially multithreaded testing, more awkward and error-prone: tests have to set and reset global variables
It's easy enough to refactor (A) where needed, as long as you have control of the code, and (C) can be worked around with good enough test helpers.
I think one can reasonably argue both for and against the convenience outweighing these downsides.