I think some of your critiques are making assumptions that aren't necessarily the case.
"If this is a mission critical application, why didn't "Kris" have a fail over contingency plan?"
We don't know how critical it was, just important enough that it being down for days led to some unhappy people. Since they weren't threatening to fire him, just putting pressure on, that suggests it was probably important to someone but not mission critical.
"No mention of a fail over server or cloud based solution to keep the application going."
We don't have an exact date on this, but it appears to predate the availability of cloud, so it would have to be another server or a different one with extra capacity. Another server isn't cheap. It's not automatically his fault if the request for that level of overprovisioning was declined.
"Why wasn't there a service and support plan on the server?"
You assume there wasn't. Someone got called out, didn't they? Why couldn't that have been as a result of a support plan? They could have one which guarantees a support person shows up (which happened) but doesn't automatically cover all expenses, hence why they would expect to pay afterward, especially as there were new parts brought in as a result of the failed attempts.
"Since they pay for each repair call, why doesn't "Kris" have some spare parts on hand."
You assume they pay for each call. Perhaps they only pay for parts, and their support plan requires that they only use authorized spares. Why buy a ton of those if the engineer is supposed to bring them? Also, how do you know they didn't have some of those things. Maybe they replaced a broken power supply with their spare a while back, hadn't received the replacement spare, and then the engineer decided power supplies had to be replaced (for no good reason as you've already stated) and made them get two new ones. You can assume any level of competence you like, and assuming the lack of it doesn't prove it any more than assuming they planned for everything.
"Where I have issue with "Kris" is where he blames the repair tech for a wrong diagnosis and the amount of down time."
Both being the tech's job. The tech should try to diagnose things rather than just swapping out parts every three days until it worked. Had the tech tested each component, leading to a day's downtime while he went through everything he could think of, I don't think there would be that much complaining as the downtime was necessary to identify the problem. However, the tech's approach didn't appear to check the hardware very much, so most of the downtime was waiting for stuff that wouldn't be needed if the tech tried diagnosing the cause instead of guessing.