Persistent Scene

A lot of your question sounds like advice on an architectural decision, and frankly that's something that really is up to you. I will say that this idea is possible and that I personally have used it successfully. Whether it's good completely depends on what the rest of your game will be like.

With regards to any performance or extensibility concerns, there is no difference. Using DontDestroyOnLoad() to make a persistent GameObject has the effect of moving that GameObject to the 'DontDestroyOnLoad' scene, which is already a persistent scene that gets created as needed. If you only really need a monobehaviour or two to run persistently, this is the easiest way to do this.

The main reason to use a persistent scene that you create by hand and load in via SceneManager would be if you have a number of objects and scene settings that you want to apply globally and persistently. Generally, in this case, the other scenes are conceptually part of the whole that the persistent scene represents, rather than complete scenes themselves.

I am currently working on an open-world game that uses persistent scenes not just for persistent data but also global objects such as the UI, sun lighting, and networking, and even to apply global lighting settings. This is a good example of where Don'tDestroyOnLoad is less useful than a persistent scene- I don't need to apply an extra component to everything or create another script to instantiate them, and I can see changes immediately as I change them in the editor.

A previous project of mine, on the other hand, had a single persistent GameObject with a few large scripts that simply controlled networking and did simple IO for player save data. This is an example of where persistent scenes are unnecessary and cumbersome, as all of the functionality was fairly simple, and this way I could load and unload scenes as usual without needing to do any sort of scene management whatsoever. In this project, scenes corresponded to levels, and there was no need to do anything with them other than load the next one in.


So, long story short is, it depends on what you're making. This is a choice you have to make as a developer, and it largely comes down to the structure of the rest of the project. There are pros and cons when it comes to workflow, but no big difference in how any of it works behind the scenes.