A few suggestions.
For the gold management, it sounds like you need access to it from many areas in your game. For simplicity, I might put both the data structure that represents the gold and the functions used to manipulate it all in an autoloaded singleton - especially if those manipulations are somewhat complex. Then, rather than individual scenes directly manipulating the global data structure, they'd just call on a single set of global functions to do that manipulation (increment, decrement, reset, ...)
That has a number of advantages, including:
- You're not writing repetitive gold manipulation code in multiple scenes
- You're not mistakenly incorrectly handling gold manipulation locally
- The gold data structure and functions that manipulate it can be run / tested independently of the rest of the game
Regarding your node name references... I'd first ask why you need such intimate knowledge of scene structure of your game? Ideally, each scene should be completely autonomous and able to function on its own. When you do need access to some unrelated scene element, the use of signals keeps that connection very loosely coupled, which makes for easier development and maintenance of your code.
If you do some poking around for Godot best practices, you'll see references to something deemed "signal up and call down". That's a good general principal that says if you're trying to access something in a child node, a direct call to it is generally OK as a parent is responsible for its children. However, if you're trying to access something up the tree, you probably shouldn't be making a direct reference to it, as that structure could easily change at some point in the future, breaking your code. In that case, use a signal.
Also, like all "best practices", it's just a rule of thumb - not a requirement.