Module names are, effectively, global variables. The reason global namespace shouldn't be polluted is that it's so damn useful. Not using it for anything is like never driving your car to avoid wearing out your tires.
You realize that there's a war between people who write static code analysis software and "software architects", the former trying to detect global state buried in object hierarchies and the latter disguising global state as something else in the interest of "decoupling" things that need coupling.
Every class property is effectively global state (has the printer been initialized? what objects of this type have been created?) If you don't think class properties are useful...
Globals are a tool. Used badly they're terrible, but so are design patterns. For a long time many very useful pieces of software ran very well with lots of global state, but the egregious cases of misuse spoiled it for everyone. The problem with the "never use globals" approach is that if you need them, disguising them as something other than what they are makes things FAR, FAR more difficult to reason about.
I agree. For example, the OO project that I'm working with at my job has a bunch of global state, but it's hidden in references to structs and pops up in a million different places throughout the system. It's still spaghetti code but it's spaghetti code with namespaces.
The point of OO isn't to separate or eliminate global state itself. At some level everything is global(agreeing with you). The purpose of OO is to establish a strict separation of concerns. The idea is to say "We need a component of our system to deal with the Blargle operation," and then determining what elements of the system the Blargle functionality actually needs in order to be performed, then making sure that Blargle is aware of only those parts of the system. Additionally it means that system components that existed before Blargle was implemented are still blissfully unaware that Blargle is a thing now.
All of the features of OO languages, like encapsulation, inheritance, design patterns, and messaging are there to allow you to write software where unrelated components can be implemented and reasoned about entirely in isolation. You can do this in any computer language, and systems like the Linux kernel are good examples of separation of concerns that don't happen to use an OO language. You can also do this with global variables, but it takes more discipline.
There is some state that is global. Current user for instance, it is used globally, so why create a complex way of passing it around instead of just making it global?
And then that is not a global state, my point is that there is global state, and trying to go through all kinds of academic exercises in "proper software design" is unneeded complexity. It's a tool, don't use it for the wrong job, but don't dismiss it just because other people use it the wrong way.
One reason is that, if you have to pass that information to functions which use that information, you can easily see which functions rely on this global state, and which don't. The usefulness of this and the annoyance of passing it manually depends on the situation, of course -- read-only "state" like the current user, and write-only state like some global logging interface, is the sort where one function's use of the state doesn't materially affect another function's behavior, so it's more OK access directly than other state. (Another example: the database connection configuration info might be unchanging and read-only, but it's real useful to pass it around manually, because then you see exactly which callees are opening database connections.)
Short course, that one.