Interesting points on the topic of hiding the fact variables are global. This generates a LOT of discussion and arguments in Enterprise space. For example, a standard technique in Java is just to have "public static" members of a class. As long as the class loader you are referencing has that class you can access that variable anywhere. OOP Priests will complain and whine and waste effort creating non-public singleton configuration frameworks (which, still at the end of the day accomplish the same thing) and in 6 months everyone will have started writing public static members again to avoid it! Having been the culprut of this at least a dozen times, my response was always, "I needed it done today. You are free to raise a tech debt Jira for it. Let's move on."
Another approach is using some form of dependency injection such that all the classes keep all their stuff private and you let the framework inject them where they are needed.
It's a paper cannon. You just inject the dependency into your code and effectively, it IS global. It's just the framework giving you the reference where ever you want it instead of you making it public yourself. It's the same thing just spelt different and the only meer improvement is that technically, you have a little more control. If you can stop other developers giving themselves control. It becomes a race between people giving themselves access to things and people trying to secure the code against the same engineers who are writing it. It wastes so much time, effort and money and barely achieves anything beyond making it all a little more complicated and costly.
If you follow on down this route through Java you will start to encounter frameworks which practically write a whole new language on top of Java with almost every single member variable existing as an "implements Optional, Immutable" and insisting on making all state read-only and forcing you to use specific syntax and proceedures to modify state. Note that this WILL require a LOT of copy by value mechanics as actual (pointer) references are not sufficiently protected in Java. (Pedants: I mean literally return obj.cloneAsImmutable() type stuff.)
I think it matters what you are doing in the code. Can a mistake (by machine or man) by undone easily? Is there a threat to life involved? I can see how a system modifying a critical value in a plane's air data computer must go through checks and balances and there has to be proceedures, such as multi-sensor elections, value averaging, limits, exceptions and so on and so forth. (relevant case of Toyota's ECU code causing some accidents, poor buggers had code analysists publish their static code analysis and tech debt lists in court).
EDIT: I think the aim of protecting the code can either be it's criticality as above or maybe it's security. Usually it's not the intent to protect against mallace within the engineering team, but rather to protect against accidentally modifying something in a way you shouldn't. Protecting against accident, ignorance and possibly negligence. (or incompetence)
The trouble is... people get interested in that stuff, start to learn it and in order to continue to learn it and prove it was worth learning they try and enforce it everywhere.
Writing C for MCUs is a breath of fresh air when you see things like blind, bare, global functions and call backs already declared. Coming from enterprise world, this ironically almost seems like black magic voodoo, exactly as an MCU engineer would see something like JNDI dependency injection.
EDIT: I noted that STM are currently under going a battle of similar lines in their HAL libraries. Lots of IFDEFs popping up removing the "legacy weak global callbacks" and making you registerCallbacks (inversion of control pattern). Welcome to my world