I work in hardware development, and without the ability to release updates after something has literally shipped, embedded software has to follow the the opposite philosophy.

I've found that the forced do-it-once-and-do-it-right philosophy requires so much less total development time than the break-things-and-release-often philosophy that I've adopted it on software that I could update after the fact.

The biggest impediment is that you may be relying on a software stack adopting a different philosophy. No matter how good your software is, if the underlying OS or libraries are buggy, there may still be poor reliability.

Using standard C libraries is a pretty safe bet, whereas relying on Python or Node.js libraries means you'll need to issue constant patches, even if your software works fine, and the fixed libraries might even break compatibility.

Given the option, running your software on OpenBSD can give extremely high uptime as critical updates are rare. They have a philosophy of not only looking at what they write, but looking at it again later, even when they haven't changed anything, just in case they made a mistake.