Without getting too specific about Armory, I’ll speak in the abstract to this question.
Most of the time a game-engine has a queue of “things to do.” When some part of the system wants a subroutine to be called “soon,” it creates a record – let’s call it an “event” or a “to-do” – and adds it to this queue, which is serviced by the main game loop on a regular basis. (But, not synchronized with “frames” and so on …)
So, “initialize the new scene” is placed onto this queue before the main loop is started, so that it’s the first thing to be done. The game’s overall state is set to something like
NOT_YET_STARTED so that other parts of the game logic twiddle their thumbs until the initialization routine finishes its work and sets the game-state to something else.
This kind of design works well because “it isn’t an exception to how the game normally operates.” The first thing that we do is to start the engine and leave it running, having pre-arranged for the first thing(s) that it will do. Code to set up the first level can be more-or-less reused to set up the next ones without building-in too many special cases. So it’s very clean. Sometimes you’ll see a more-elaborate game initialization (or, level initialization) process that is broken down into many “queued events” that queue one another, that arrange for “call-back events” to be queued at the right times, and so on… (This might be done so that several threads, each of which are being driven by the same event-queue, can work simultaneously.)