Hi,
well.... long post coming on that one 
The problem is that organized structure is always paying off in the long run, it's something that experience tends to bring on the table.
...
I see your point of view. I kinda figured these globals acted like public static elements anyways.
In the bigger industry (outside of small indie projects) one would logically go traditional and full code with a slightly larger team, and perhaps (at best and this is not to disparage Playmaker) allow bits of Playmaker only for the sectors of development wherein the employees would have access to a more visually intuitive approach to problem-solving and testing. Case in point, Blizzard's card game, Heartstone, for which I think Playmaker was introduced in the design process of cards, before the data would be serialized into classical data form and nothing about the Playmaker engine got put into the app.
As far as it goes for my little project, if for some reason, I had not planned a multiplayer function and would have to add one, and assuming that I would have had enough foresight as to isolate everything strictly related to my player into a "block" (game object acting as a folder) within the app's hierarchy, then copying that block would copy all the references to the same globals and I would then have to manually change them one by one, likely having to point to new globals intended for player 2.
That, for the vars that are strictly player-centric.
This is however not going to happen though and for simple projects, globals easily find their sweet spot in builds.
This problem would also be solved (I think) if one could tag (or group, a different approach) globals such as under a tag:player_1 and associate these, therefore, to some object or block about P1. Assuming a few more functions, duplicating the player block would also duplicate the globals tied to a player block, all with new names and references, and automatically tag/group them into a group dedicated to P2 (so on and so forth).
I may be wrong here but I would tend to think that near-full Playmaker projects are mostly limited to small scale products where major groups of functionalities have been planned ahead. I don't have examples in my head of large projects relying solely on Playmaker, involving teams of five or more people. But the small scale approach and a lack of sudden unfortunate surprises would tend to make globals reliable enough.
For what it's worth and to be add more grain to the mill (and yes, this thread is being so horribly hacked), I'd like to highlight what I deem useful about globals. First of all it's easy to know where they are used. Secondly, their exposure and how easy it is to access them are advantages.
The problem being that they are fixed.
So, could similar attributes be recycled to be crafted onto the usual local variables so that these local vars may be alterable in a way as to make them "enhanced local vars"?
Perhaps there should be a way to make local variables easier to access, without necessarily turning them into Playmaker Globals. Like a way to make them read and/or write ({get / set}) which would help circumventing the tedious addition of Get/Set Fsm var actions, with perhaps an option to isolate/limit them to specific game objects with modes such as "same-level-hierarchy", or "children only", plus eventually the possibility to use the / to create a group for the variable to appear in; the group could either be a name or a reference to a game object.
So when the user clicks on the variable popup menu in the action settings, there would the locals, then the vars with new abilities, and then the Globals, assuming you're trying to access the variables from a FSM that's an object that is meant to have access to the enhanced local vars.
And these vars would need to have a way to be added to groups which can be monitored in their floating windows, including what game objects and FSMs are using them.
