Language implementors are a very special case. Their effort is O(1) while the other two are O(amount of code in the language). In any case, I don't see what your point is.
---
I think you're conflating things too: NLL is defined in terms of a CFG, which happens to be MIR at the moment, but if the current MIR is insufficient for some task, it can still be fundamentally changed, with the NLL semantics handled specially, e.g. with a multi-step lowering, like HIR in Rustc.
The mid-level IRs chosen for a compiler are in service of the high-level language and its tools (like formal/static analysis), not the other way around.
In fact, a static analysis or formal reasoning tool likely needs more information than fits into a compiler/optimisation-focused IR. (You see this even with LLVM IR vs MIR and SIL etc: LLVM IR can't hold enough info for the front-end to do everything.)
---
I think you're conflating things too: NLL is defined in terms of a CFG, which happens to be MIR at the moment, but if the current MIR is insufficient for some task, it can still be fundamentally changed, with the NLL semantics handled specially, e.g. with a multi-step lowering, like HIR in Rustc.
The mid-level IRs chosen for a compiler are in service of the high-level language and its tools (like formal/static analysis), not the other way around.
In fact, a static analysis or formal reasoning tool likely needs more information than fits into a compiler/optimisation-focused IR. (You see this even with LLVM IR vs MIR and SIL etc: LLVM IR can't hold enough info for the front-end to do everything.)