As soon as you said "global Singleton" and "signal" I went, "Oh, a fellow Godot user!"
While these concepts exist elsewhere, they are not as commonly referenced in game dev - but they are staples in Godot.
Here is a random collection of tips and thoughts on how I organize things in Godot (my fav engine):
SINGLETONS:
Personally, I've been increasing my use of global singletons for optimization purposes. (For example, I use them for my audio library so I don't have to search everywhere to find a sound effect.) This also helps me front load some parts of my games at more appropriate times (like during menus) so my framerates don't drop.
I always have a "GLOBAL" script that holds certain library functions I want everything to have access to (like playing audio). My global singleton holds references to key nodes that I set upon loading. For example, I use "var CAMERA" in the global singleton and then the ready function in my Camera's script starts with "GLOBAL.CAMERA = self". This way, anything can easily reference the camera with "GLOBAL.CAMERA" without having to waste time referencing the tree root or figuring out how far down the tree I set my camera. I can move my camera up or down my tree during dev time and it will always be findable at runtime.
Other items I have done this with include: HUD, PLAYER, CURRENT_LEVEL, and DATABASE...
SIGNALS:
I like using the built-in signals, but for a lot of things, custom signals can make things harder to manage. I know it isn't the "preferred" way to do things in Godot, but I don't mind tightly coupling some things even though it reduces reusability. There are a lot of tradeoffs in coding: readability, speed, efficiency, reusability... We all have to choose what we want to prioritize with each script we write. For game mechanics, reusability isn't my highest priority. (That said, I have a growing folder called "Utilities" that I generally just copy-paste from one project to the next. So for *some* things I care about reusability.)
SUBNODE REFERENCES:
Anytime I want to reference a sub node in a script (eg: a sprite); I will create an onready variable at the top of the script.
"onready var MySprite = $sprEnemy"
Then I use the variable (eg: MySprite) in place of referencing with the "$". This way, if I later move or rename the subnode (which I do a LOT), I only need to change its reference once. Also, I use a consistent naming convention for both subnodes and subnode references (eg: the sprite for something is ALWAYS labeled as "MySprite"). This way, there is never any question what is being referenced and it makes script reuse easier.
LABELING:
I also recommend being mindful about folder use and naming conventions. In my current project, I have a folder called "Enemies" and everything in there has a name that starts with "Enemy_". I also have a folder named "Levels" and every item starts with "Level_" or in some projects "lvl". Personally, I prefer to keep my scripts in the same folder as my scenes rather than make one HUGE folder labeled "Scripts".
Use subfolders! Under my Assets folder I have sub-folders labeled "UI", "Audio", "Fonts", "Shaders", and "Art". Under "Art" I usually have subfolders like Enemies, NPCs, Player, Background, etc. Under "Audio" I have "SFX" and "Music" separated. I prefer to name my assets with what they are "red_spaceship_coneshape.png" rather than how they are intended to be used "level1_bkg_music.ogg" because I might change my mind about how it is to be used later.
ART:
As often as possible, I like to use black & white art assets and color them in using either shaders or the self-modulate function. this allows me to shift color pallets on the fly. I'll even have colors named in my GLOBAL script "MyBlue = Color(#41d7d7)" and then reference them "set_blink(GLOBAL.MyRed, GLOBAL.MyBlue)" for things like hit effects.
ANIMATIONS:
Tweens are your friend. Not really an organizational tip, just a fact.