My instinct from your response is that if we chatted on this for a bit in person we'd see eye to eye and we're probably thinking of different use cases, because

My instinct from your response is that if we chatted on this for a bit in person we'd see eye to eye and we're probably thinking of different use cases, because I can see how thoughtful you are and usually it comes down to thinking about particular problems in particular companies. So at the risk of going back into crass generalizations, I do persist in thinking that the TCO of a monolith is lower under a lot of the constraints you're describing, assuming (big emphasis) the tooling of the language you're using for the monolith, i.e. a combination of linters and compiler, can enforce the rules. I've been in service-first environments where the equivalent of not caring about code quality in the monolith is firing up a new service without consideration for refactoring the older service, until I am in endless architecture meetings about how to make cross cutting changes around a bunch of services everyone regrets creating. I suppose in the end it comes down to the classic issue of needing to pay down of tech debt, which is true in any software ecosystem.