The fact that NASA managed to crash a probe into Mars because they hadn't yet learned the lesson says it all really. Just use SI units and stop worrying about it.
You measure mass in kg, not g, not tonnes.
You measure distance in metres. Not kilometers. Not nautical miles.
You measure time in seconds.
A Newton is a derived SI unit — 1 kg m / s^2
Incidentally, this is why engineering notation works the way it does. You pick your units and you get the significant figures from the mantissa and the descriptive prefix (giga, nano, micro, kilo, etc.) from the exponent.
There are plenty of applications where it makes sense to do something different because you need to accommodate special hardware (e.g. FPGAs), because you want a different representation density/range, or because external policy effectively dictates the most natural format (e.g. finance). But in the absence of a pressing concrete reason to ditch 754 floats, they are BY FAR the best option for high performance, reproducible, portable, debuggable math with abundant documentation and pre-existing pools of expertise. They're far from trivial but so is the fixed-point code you would replace them with.
If someone couldn't be bothered to learn the relevant intricacies of IEEE754, why do you expect them to do a better job re-implementing the stuff on top of integer math (or picking apart the in-house attempt to do so)? Shifting from problems of the "intern forgot to reset the rounding mode" variety to the "Newton's method code erroneously terminates one cycle too early if the last bit is a 1" variety hardly seems productive.
Also, remember, people are representing these numbers on computers. Derived units are very useful—in fact they are often critical to achieving necessary accuracies using compact representations. Further, representing quantities in terms of other unique, problem-specific units is often extremely helpful for ensuring good numerical behavior.
Furthermore, you are suggesting that the same entities--highly trained engineers and scientists and project managers--that proved inadequate to follow the policy you are suggesting last time can somehow be expected to follow the policy correctly at all times in the future.
Reducing needless complexity--in this case by enforcing a standard of common units so that when the inevitable inevitably occurs and someone forgets to label things--there is a much reduced (but still non-zero) chance of undetected mis-matches occurring.
Furthermore, it is very difficult to confuse milli-newtons with newtons even if a project was for some reason using both, because they differ by three orders of magnitude, which tends to get noticed. Whereas kilograms and pounds differ only by a factor of 2.54, which might be--and in fact has been--missed.
Have you actually studied the mishap? If labeling and verifying the units was done carefully it would have prevented the accident.
A millinewton/newton mix-up could easily occur in a case like this one, too. The particular numbers which were misinterpreted in MCO's case were often small, and I can easily believe no one noticing similar ones being a few orders of magnitude off. (I do have a hard time imagining it with MCO's particular numbers, though.) Similarly, you can be bitten by a meters/centimeters switch or accidentally using different representations of the same quantity, such as specific impulse and its corresponding characteristic exhaust velocity, which only differ by a factor of about 10 when both are expressed in SI units.
I maintain that the key lesson is to always label your units, and to test them carefully and routinely, including at interfaces. I believe that claiming that using English units (as gross as they often are) caused the failure misses the more fundamental root problem.
(Also, I'm not claiming that labeling and verifying units is easy. I emphasize it partly because it's hard. Little of our current software ecosystem includes any concept of dimensionful numbers.)