What a landing zone actually buys you
Landing zones get sold as a best practice. The honest case for one is narrower and more convincing: it is the cheapest time to make decisions you cannot easily reverse.
Most teams meet the phrase after the fact. Projects exist, workloads are running, and someone asks whether the structure underneath them will survive an audit. The answer is usually no, and the work to fix it is no longer a design exercise.
The decisions that are expensive to reverse
Four things are hard to change once workloads depend on them: your organization hierarchy, your network topology, your identity model, and where the boundary sits between environments. Everything else can be refactored. These four get baked in by the first serious workload and then defended by every workload after it.
A landing zone is not a product. It is the point at which you make those four decisions on purpose rather than by accident.
What it does not buy you
It does not make the migration faster. It usually makes the first workload slower, because you are doing work that the first workload alone does not justify. The return arrives with the fourth or fifth, when the questions that would have stalled each one have already been answered once.
It also does not substitute for cost governance. A well-structured environment with no budget alerts and no committed-use planning will still surprise you.
A reasonable sequence
Start with the org hierarchy and the policy set that applies at the top of it. Add identity and the group model before anyone is granted a role directly. Then network: shared VPC, the service perimeter, and how environments reach each other. Cost controls last, but before the second workload, not after the tenth.
If you are already past this point, the useful question is not whether to retrofit everything. It is which of the four decisions is currently costing you the most, and whether that one can be changed while the others stay where they are.