I like the idea of a deep connection between IT and business. However, I'm not sure the other stuff you're proposing is viable for run-of-the-mill stuff, although it does seem viable for high impact stuff (which isn't what people usually work on).

Run-of-the-mill projects tend to run on a bunch of features which have very low impact on their own and, with some exceptional cases, are probably useless on their own. Unless you're building sonething like a common platform + apps where you can still play Solitaire even if Minesweeper goes down, things are still highly interconnected. So I think it's usually far more valuable to push for outlandish external resilience instead of trying to make the individual components resilient to outages on their own.

For example, it would be far more valuable to choose PostgreSQL for a database in spite of Oracle or Microsoft or whatever promising lower TCOs somehow because that couples you less to a single vendor. And at that point you can go full in on PostgreSQL and not even consider database portability (which tends to be tricky on its own). This may also result in a decrease in code complexity, which makes your code more internally-resilient.

Yes, if reasonable and accessible, go ahead design for graceful failure. But don't go out of your way to make things independent when they cannot be so morally, because even if there is some benefit costs will skyrocket. There is little point (although it might be nice to see general pricing) in taking orders if they can't be paid, to follow one of your examples. At least not if you have to jump through hoops to make it do anything sensible. I'd rather write tight code and cover all "normal" corner cases (might seem like an oxymoron but it isn't once you consider that some things like memory management or availability of direct function calls is usually taken for granted), without introducing extra possible failure modes.