Oh, state machines!
First, I will refer to your direct question - you are asking about different scenes. As the page you are referring to states (no pun intended), you can use a single scene for your entire experience. The concept of scenes in Babylon is more of the concept of the graph of resources that you are currently using, and less of a “Scene” concept in a movie, for example. If you cleverly manage your resources in each scene, loading them only when needed, clearing them when not, using the scene’s powerful graph-control features, it makes sense to have separate scenes. However, it can always be achieved with a single scene.
It’s all a matter of taste to be honest. Instead of multiple scenes, you can use asset containers , for example, to control the resources that are a part of the current stage (or “scene”
) in your experience. This way you have a single scene, with a single render call, and you don’t need to manipulate the render loop to decide which scene to render.
The document you referred to shows one way of dealing with scene’s state changes. There are, as always, many others. It’s a matter of your personal taste. Personally, I would rather have a “CurrentScene” class that has a reference to a single scene, and that allows you to change the “current scene”. This way you achieve this state machine with a single class - You know when a scene is stopped, you know when it is time to initialize a scene, and you know when the scene should start rendering. Cut scenes can be scenes too, in this case! However, this will still require you to have some control over the existing scenes, their resources and so on. There is no way around it.
If you do want to use the same concept as offered there, yes - you will need 30 cases in the switch loop, otherwise it won’t work. Not sure if default is needed or should be of any use, but this is a different topic 
And something general - using a framework that gives you the freedom to make your own decisions has an interesting downside to getting started - what is the best way to do things? configuration, convention, does the framework provide a solution to my problem, does this solution solve my problem efficiently? Our docs provide examples and ways to solve certain issues. Sometimes it refers directly to core functionality, sometimes it provides tutorials of ways we (or more correctly - the person who wrote the doc) think things can be done. This, by no means, mean this is the only way or the best way. The more you will experience with the development of your experience, the more you will understand what fits your usecase, and you will be able to implement it correctly.
I’ll give you an example - let’s say you use the same meshes in all of your scenes. Since meshes are scene-bound, you will need to load the mesh to each scene. Memory management here will be chaotic, unless you craefully dispose resources. And, it does add some extra time to actually load the asset(s). Of course, there are solutions to it, but in this case, would the better solution be a single scene with the needed resources, and a state management control on top of it? So instead of multiple scenes, you have multiple stages in a single scene?
I can go for hours…
But I think you get my point - follow your instinct as a developer to make your use-case the most efficient. We are always happy to provide input, suggestions, help with issues, but eventually you know the best what you want to do. Following the tutorial will provide you with a lot of information about the ins and outs of Babylon! But a tutorial is (usually, and also in this case) written after a long deliberation to the architecture that will fit the experience in the specific tutorial.