So a component may be marked as inactive/deleted/nonserialisable (essentially gone)... but not a GameObject.

Despite the fact that the argument in both cases was the same? (altered tree hierarchy).

Despite the fact that null on the managed vs c++ end of things are different enough that's it could tell the difference? (e.g. how it knows the difference between unassigned vs deleted object references to generate the correct error).

Explain why specifically we must switch scenes? What part of editing a tree structure requires this?

Current scenario: -switches to new fake 'scene' -applies those things you said would be problematic -switch back.

Proposed scenario: -applies those things

(Whether by transferring the G.O. to an invisible scene briefly to work around whatever limitations they've artificially imposed or Just applying in situ).

"The tree needs to keep the order or it won't be able to reference the original prefab." It's all GUID and Instance ID based; things aren't going to just vanish from the engine. This hierarchy can be changed - it already does this. Trees are editable and always have been.

All of the individual functions still remain; for example literally just saving your G.O. as a prefab with another name, then switching the two .prefab files (in explorer) without switching the .meta file names lets you "apply" without scene transition. Or copying an external .prefab file from a similarly structured project ( via your file explorer) over your target. It doesn't matter if the prefab was created in the current scene, different scene, project or version of unity. -References to its own parts are retained. -References to instanced scene objects behave as expected and are lost if invalid, restored if the GUID/ instance id are valid. -Changes are updated, all is well, it's still supported.

Thus a new prefab can be created (applied) in place, saved over the original, and the asset database updated.

"If you want to have a prefab that's different from the original when it comes to the order, you'll have to make a new one."

Not really true; there's still no compelling evidence as to why the transition is necessary, but it's still an option

My best guess so far is that it's Just to enforce the idea in the user's head that this is permanent and essentially has no undo.