My reading of the passage you quoted is that it's not telling you, as a user, "Don't use these static fields we gave you. That would be bad coding practice on your part" (Well then why did the creators expose them? Meanies!)
Rather, it's saying "As a general rule, exposing these static fields is bad coding practice on our part, but we consider it to be a worthwhile trade-off to make it easier for you"
So, there's no particular prohibition on using these modules via their static fields. Since they were designed to be accessed that way, and the creators were apparently conscious of the ramifications of this choice, you're unlikely to create trouble for yourself by going with the flow they created. (And in any case, you can't stuff that genie back in the bottle - they remain globally accessible, with all that comes with that, even if you try to maintain your own more controlled method of accessing them)
In your own code, creating your own new global variables this way can open the door to bugs. Once something is global, it's hard to track down where any particular change to it came from, and it's easy for unrelated parts of your code (or libraries you're using) to do contradictory things with it, unknowingly interfering with each other.
It can also make the code hard to scale: if in the future you need multiple instances of something you used to access via a global variable, or multiple flavours of it, now you need to refactor a lot of code to select the right one.
For these reasons, a number of other patterns are often recommended for handling these kinds of dependencies, such as dependency injection or service locators.
But again, you don't have to worry about that for the built-in modules that are already exposed via static fields. The creators of those modules already weighed these alternatives and decided global access was safe enough and worthwhile for this case, and as you noted, a lot of software uses them this way without issues.