I think there is agreement, or at least slowly developing consensus, that some software should be "engineered" and some should just be "developed". But there is not yet really a structure (that I have seen) for declaring which thing your project is doing and setting up your practices accordingly. One reason this is tricky is that many (most?) projects start in the should-be-developed category and only transition to the should-be-engineered category later after they become mission critical in some way. The answer is often to build an "engineered" version as soon as you can figure out you need it. But then that's even more expensive than doing it that way to start, and it's also a really tough call to make because everybody knows rewrites are a bad idea. It's a tough bind for all but the most obvious cases. And then because those obvious cases are fairly few and far between, the best practices and the experiences of most of the workforce are skewed toward software that merely needs to be "developed".

To make this concrete: a couple times now in my career I've embarked on projects where setting up any level of formal verification at the beginning would have clearly been overkill, but where a few years later I really wished I had it for certain important pieces. And now since formal verification is so uncommon in my experience, I would have to play a lot of catch up to do it, even for a project that is clearly important enough for it even from the beginning. I think this is a pretty widespread experience.