I think where you are getting confused is in understanding the separation of roles between the disk, RAM, and the CPU.
The "disk" and RAM are storage devices, while the CPU does computation. Thus, the CPU doesn't really "store" anything - rather, it calculates your game's state by running your code. RAM is what actually remembers your game state between frames, which means it has to store every instance of every scene in your game.
The difference between the disk and RAM is that the disk is for long-term storage (your computer's file system, which is where your game lives), while RAM is for short-term storage. Getting stuff in and out of RAM is much faster than getting it in and out of the disk, which is why the resources in a game are first "loaded" into RAM. This is what happens when you load
a scene in GDScript - it gets pulled out of the disk and into RAM, where it can then be instanced. But here's the thing - every instance you create also has to be stored on RAM, because RAM is the only thing that can "remember" your game state between frames (the CPU just performs calculations). So every instance in your game - whether you instantiated it at runtime or if you drag and dropped it in the editor - takes up space in RAM.
While RAM space is something important to keep in mind, you also want to take care not to strain the CPU unnecessarily. This can happen if your code is inefficient - for example, by updating your UI in every frame using _process()
rather than only updating it when something changes (this alone won't cause any serious CPU strain, but if dozens/hundreds of nodes abuse _process()
in this way, it can cause trouble).
To summarize - having thousands upon thousands of nodes/scenes can overload RAM, while running a ton of inefficient or complex code can overload the CPU.