Sadly, most of us don't have the luxury of working in environment where (a) it's mandated that we set up a 1-for-1 test rig with the production infrastructure and (b) management will accept the answer "I need to test for all possible contingencies because failure is not an option."
(Most of us are writing code in an environment where failure is totally an option, as long as it's fast and restoration is quick ;) ).
Another part of the difficulty with updating servers is that updates are rather opaque. My own software on any given server is maybe 0.1% of all the software running on it (if even that). The other 99.9% is someone else's code: the operating system, the software runtime, the libraries, etc. So one doesn't really have a lot of insight into what is about to happen to the server without running a duplicate setup, which as you point out is pretty difficult to get right. I'm sure NASA has much more visibility into all the software that is running on their spacecraft.
While the abstractions is lesser for a spacecraft, I don't think any one is hand compiling or writing machine code directly. There will always be some abstraction layers.
While the requirement is there, often it falls through the cracks. A recent example is the wrong mapping of the Starliner thrusters. This wasn’t found until the simulator changed due to brownouts after it was already in orbit. Just by luck, the new simulator was of sufficient fidelity to catch the mapping error.
Had 1) they not missed the correct orbit due to a different issue and 2) not had to switch simulators it could have potentially collided with the space station.
So yes, the requirements are there but often not followed but luck was on our side
The mission has a very small sliver of that budget. Trust me, there's no "NASA" that comes running when things go wrong: It's on the mission team to handle it.
God dammit. And here I have trouble getting software updates into a server I have full control over on Earth.