In anything that really matters you have a continuous position transmitter instead of switches so your state is more obvious. In safety systems you might have 2 or 3 of those transmitters so you can have a backup or a vote
This meant that we would have to make assumptions like "you (other subsystem) say you had the payload and you gave it to me, and I believe you, but I can't prove that you did until much later in time."
And if it turns out that we weren't actually holding it, then recovering from that state required unwinding a whole series of decisions and actions made some time in the recent past.
Suffice to say, it made error handling for certain cases... challenging!
Having an absolute position sensor would tell you this, but is complex and expensive compared to having two binary state switches (fully-open vs fully-closed) which is also more expensive than a single state switch.
Probably in many cases it just isn't worth it to instrument beyond the single state, especially if the affect of the control is being monitored (eg: flow, temperature, power). However, communicating the state as accurately as possible is important to avoid confusion ("This valve says ON, so that's not the problem" vs "I can see this valve is NOT OFF, but let's double check it's fully-on?").
The config file can't guarantee the interface will be up when it's loaded as that depends on external factors but it can guarantee the interface will not be shut down.
I've used "no shutdown" as an example of illogical UI for decades because it seems backwards as the user, especially when new to IOS and trying to learn by exploring, but from this perspective it makes sense.
> but from this perspective it makes sense
No, it's just a clunky way to remove the config line, it has nothing with the engineering safety.
It's still better than Huawei's lingo, though.