Could you develop a game using only the Unity Editor, and not writing a single script? You could, but the game would be very limited. While you could create extensive scenes with complex GameObjects, these GameObjects couldn’t do anything interesting beyond obey the laws of physics (gravity and collisions). Anything more sophisticated requires scripts.
Conversely, could you develop a game using only scripts, and avoiding the Editor completely? This would be quite do-able, as GameObjects (and all their components) can be generated programmatically. And while there are a few thorny initialization and setup issues, and some project settings that need to be selected through the Editor, a complete game could conceivably be 99% script.
What are some advantages of developing programmatically? Why would one event want to bypass the Editor in the first place? It may seem odd at first, because Unity’s Editor is exceptionally powerful, letting even a beginner quickly put together objects and create scenes with very little understanding of C# Monobehaviour. But there are good reasons to develop as much as possible using scripts, and I will go through some of the most important ones below.
Want a simple mesh? A script can create one. Want a complicated terrain with a ton of monsters running around? A script can create one. Change your camera? Done. Change your lighting? Done. Whatever GameObjects and scene you imagine creating with the Editor, you can do equally well strictly through script.
But scripts give you even more power, because you are not limited to the options provided by the Editor menus. You can access the full range of public-facing variables and methods.
If your GameObjects and scenes are generated entirely by scripts, there is no chance of inadvertently skipping components or properties during review and development. This contrasts with GameObjects created through the Editor, which rely on a (unrecorded) sequence of button pushes, drag-and-drops, and so forth, all of which may be further obfuscated when turned into prefabs. As long as everything is created by scripts, it is possible to review every step of their creation.
Because scripts are just plain text, their changes can be tracked in a version control system like Git. Along similar lines, the fact they are simple text files make scripts very easy to be viewed and edited by multiple people.
When you are using the Editor to create GameObjects, you tend to modify their positions and properties with mouse clicks and drags. This opens up the possibility of errors like setting translations and rotations to not quite zero (say, 0.01, because you didn’t drag its value completely). Or imagine a GameObject composed of many other GameObjects, where they are all touching each other. Dragging and dropping, and setting their positions visually may enjoy artistic license, but doing the same with scripts guarantees arithmetic precision.
GameObjects created with scripts can be duplicated a huge number of times - possibly each with small but precise changes - through, e.g., for-loops. On the other hand, GameObject creation with the Editor restricts you to one object at a time. Even cut-and-paste only goes so far, as it doesn’t give the flexibility of changing the GameObjects’ properties for each copy.
If you are not artistically inclined, designing a scene can be daunting. Even if you become skilled with the Editor tools, visual design can only take you so far. On the other hand, script-based design lets you specify the GameObjects numerically and algorithmically, and avoid the trauma of “electronic painting.”
Ultimately every script needs to be attached to a GameObject. That’s just the way Unity works, running through all the GameObjects and executing their scripts. You can create classes that are not attached to GameObjects, but rather used by the scripts in various ways (for example, classes holding and manipulating data). But unless a class is referenced by a script attached to a GameObject, it will never be seen or used by Unity.
On the other hand, scripts can not only create GameObjects, but can attach other scripts (or themselves) to these GameObjects. In other words, the entire GameObject / script hierarchy can be done from within a script, with one exception. Even an all-generating script must itself be attached to a GameObject in order to run in the first place. Without being attached to a GameObject, that primordial script would never be executed by Unity.
For this reason, it’s not uncommon to see games that contain a single empty GameObject (perhaps named something intuitive like “SceneBuilder”), to which the primordial script is then attached via the Editor. Once that’s done, the script can do the work of creating all the other GameObjects, and even filling out the components of its own GameObject if desired. It’s a dent in the purity of an otherwise fully-programmatic Unity game, but it’s minor enough to not cause too much indigestion.