Well, not to be a pain, but you really can't have to fruitful a discussion this way, since both the vocabulary and the syntax of both methods, the existing scripting language for quests, and the proposed one I think by Banshee, are not fully defined or recognized by all parties. So unless you spent the whole time teaching each other the whole methodology of each, you will remain often confused by each other. That doesn't mean it isn't a very honorable pursuit, I just think the problem conversing here is the different vocabulary and experience/context with that system.
Creation is an example in the original in-game method. You can think, well why doesn't that also Place. Well technically it does, but not in the obvious game world. Think of it this way, it is a reserved Creation for later use and placement. Often this is done to make modding possible. The Quest language actually is similar to a modding language. So Creation is like an engine thing only, where Placement slaps it in a place per either a Starting Quest or a called Quest. Your Quests are basically your enactors or placers.
So the Place command is meant to bring that hidden already created item into the main game world and place it at a definitive location.
So, yes, in many languages when you Create something you place it somewhere, but here, you are placing it not in the obvious game world. Supposedly this is a bit similar in TES5Edit for a reference. You don't want to truly delete the reference when you mod something in, because if you do, and then remove the mod, that reference now needs to be put back in since the original game when unmodded had it available. This all comes from the default game being the Master Mod or File if you will, and any subsequent change or mod coming after it. Only one record can survive, so that last one is used. Well, as long as the Master Reference remains hidden somewhere, like when inactivated and slapped 50 meters under the terrain, then when the mod is removed, it can be returned as in the original.
But again, that explains little to one who hasn't had to deal with this at all. One would have to know how mod order works, how TES5Edit works, and the difference between Deletion of a Reference, and the other term that I called for now Inactivate (but the actual term is different, but as usual I forget). And I'm not that knowledgeable on the subject of TES5Edit or modding of the Elder Scrolls series anyway.
But, so the scripting language is always more like a hack. It isn't as pure as say defining a variable in a Programming Language like C. And usually Quest Lines are either done in a certain order, so their order matters, or they are also determined by what Section or Paragraph they are in. So one Section is there to define temporarily certain things. And usually as long as it is just within a Quest or a Script, it only exists for that Quest's duration, or for that Script's duration. Why? Cuz it isn't really a full programming language, it is there to hack into the game engine, get something done while it exists, and get the hell done or expire, afterwards. It's results are still in the game, if they are made to trigger key in-game results. Like writing to the Log, or providing NPCs that become corpses that provide loot, etc.
So, it's actually a terrible mindset, but it is meant to be a shorthand. Shorthands often do several tasks at once easily, but they can be terribly hard to read without the inside knowledge of what they are meant to be doing, and what other helping functions in the game they use. Think of these Quest Scripts as this sort of shorthand. There is stuff not talked about which are rules and codelets they can call from the always existing game engine code, and they hack into these. They are like long specially worded Console commands, following a special format so that the Console or the game can translate what they mean and make them work.
Maybe that helps some. So the wording is obtuse because you aren't defining Global Variables that always exist. You are using things that the Quest Script may never define, but actually exist as always available code functions. You don't have to create a new function or subroutine, because those already exist, and the arcane example of how to create 1% chance, is simply a way to save another 99 places in an array in the main game engine or some other strange reasoning.
Anyway, that's how I would see it.
My problem in the few times I looked at Quest Scripts, and I have only spent under an hour looking at any, is the format into sections and what comes first versus later, which I'm sure matter. The rest of the examples given here, the old stuff doesn't look too obtuse to me, as long as I imagine it as only a script hack into other game engine stuff for quests.
So for me, laziness is the main issue, and lack of experience with the system is the resulting problem.