In general, the parent nodes should control the children, in which case (in an ideal world) you should never need the root node or to call up in the hierarchy. It's not a perfect world, and many times you will find need to access other nodes when you are making games. This is almost unavoidable, but can be done.
One way is to use (or abuse) groups. If you put some main important objects in a group by themselves (definitely the Player could be a good choice here) then you can use get_nodes_in_group() and you know the first result is always the one you want. Kind of a hack, but it works.
Another way is to use an auto load script, Singleton, to store the node paths of important objects. This way you only have to type them once, and all other objects can query for the Player or whatever, and it works and limits the amount of modification you have to do if you change the tree structure (only update the path in one location).
Finally, you can use an auto load script again, but have the individual classes class objects register themselves. The objects only need to know about the Singleton, and on initializing, they send their path to the global script. Then you can rearrange freely and it should all work, but I never tried this personally.
Also, using Signals will help reduce the coupling to hard-coded paths, and can be used in all these solutions to further reduce what the classes know about each other. So in the Singleton, you can wire up all the signals (events) relevant to the game, and then allow that one script to dispatch to the correct object. Not perfect, but this means that that only one script in the whole game has to have any paths (and these can be dynamic) but it's also a bit more complex and probably considered bad design.
