Thanks, man! Half of it is still a mystery to me (a one-man team), but the other half seems reasonable.
No problem. If you have any feedback (or questions), let me know.
Thanks for taking the time to write this up! Some of these are things I had to learn the hard way, and absolutely agree with you, others are things that sound like good ideas to try.
I do have a question about this part:
Data Persistence and Sharing: Use the static keyword for persistent data or shared information and functionality. Consider using custom resources if inspector serialization is needed. Use autoloads sparingly for larger projects. Autoloads should generally be used only if they have no dependencies and they never have their state externally mutated.
If I’m understanding correctly, in cases where you need to share global state data or references, you’re advocating for using a named class script with static variables rather than an autoload? Beyond not having to inherit from Node, is there extra functionality you’re taking advantage of by doing this? Or is it that there’s a problem with autoloads that you’re running into in larger projects?
The one thing that comes to mind is maybe using the static variables as an alternative to injecting data into script instances, but I haven’t tried that myself. (I’ve had the impression that the behavior of static variables wasn’t reliable enough, but I think they may have had some updates in recent versions.)
If I’m understanding correctly, in cases where you need to share global state data or references, you’re advocating for using a named class script with static variables rather than an autoload?
Yes. Honestly though, this advice is more geared towards C# users, and so might be unnecessarily confusing. GDScript doesn’t support “truly” static classes from my understanding (though in practice, a static class is just as you say, a named class script with nothing but static variables and static functions, so perhaps it’s a moot point; they aren’t “truly” static for only for some technical reasons, namely, they can still be instanced and they still inherit from Godot stuff). The only reason to prefer a static class is that they are, strictly speaking, simpler (especially in C#). However, because they are simpler (no inheritance, no instancing), they are insufficient for some use cases. You can 100% get away with just always using autoloads, and be perfectly fine.
I may completely change that paragraph to make all of this more clear, or refactor it completely. Thank you for pointing out how confusing that is.
The one thing that comes to mind is maybe using the static variables as an alternative to injecting data into script instances.
If you have an object which is instantiated precisely once which needs to persist across scenes (like a Player object, or GUI/HUD objects), storing all of it’s persistent class data inside static variables (or a reference to a custom resource if that is more convenient) is probably the simplest possible solution. A lot of my architecture advice really stems down to “use the simplest solution possible”, or in other words “reduce all possible unnecessary mental overhead” (unnecessary scripts, indirection, etc).
I’d just add “Never use C# for gaming”… and that’s why I don’t write guides 
There’s a ton that can be added re: coding practices, like creating static classes to hold all frequently-used strings.to avoid magic strings throughout the code, avoiding the use of get_node like a plague, always sorting variable declarations at the top of a class by type in the same agreed-upon order (I do signals, then exports, then vars, then @onready’s, then _ vars, for example), etc.
But I think your guide was more file organization-focused, and as far as that goes it seems great and thorough, though it’s by far my weakest area since I just started with Godot and am a solo dev.
There’s a ton that can be added re: coding practices
I considered that, and originally the guide did have coding practices. But, I am way too personally opinionated about coding practices to really make advice that was generally useful to a lot of people. In particular, I think articles like the ones here, especially the second one, as well as this book, are more important reads than anything I could write.
All the specific things you suggest do make sense to me (except for “never use C#”, I am using right now and it is fine; but I am not targeting mobile or web). I could potentially make a coding section, which more or less just repeats what is recommended by the Godot Doc Style Guide in a more succinct way I suppose (and also the advice you give about keeping members consistently organized).
EDIT: I followed your recommendation of adding a script member organization tip. Thank you for bringing that up.