This doesn't seem to apply in the realm I've been working in. We've had to do the exact opposite thing.

In small, B2B software companies you may find that accepting an uncomfortable amount of liability is usually the only way to get your foot in the door. Certain promises have to be made (very carefully!) or no business would occur at all.

For example, if we told our banking clients that "if your front-line app crashes we might have it fixed in 5-7 days" just to be safe, they likely would have little-to-no interest in utilizing our solution. We have to say things like "We will respond within 1 hour and send a polite apology letter to your CTO every time the server makes a weird noise". And, we have to "engineer" our solution so that we have a minuscule chance of hitting that promised target.

Consider that in a <10 person company that there is going to effectively be some person who has to own all of the pain that comes along with these decision. Is that person not an "engineer" by some arbitrary definition? Sure. But, for the purposes of "a professional weighing all of the pros/cons and making a decision that they intend to accept all consequences for" - I think it's the same effective practice.

Ultimately, "software engineering" is a very broad space with varying degrees of professionalism. At some ends, you will find things that approximate actual engineering. At others, you will find things that appear more academic or artistic. The context is what defines the title of "engineer" for me.