I suppose it's both slower and more expensive than "just ship bad code at full price and wait", but I'd still expect more companies to choose it as the intermediate option between that and comprehensive in-house testing.
I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".
I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.
The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems.
You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".
Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out of duct tape, Google Forms, Zapier, ITTT, manual processes, and excel-wrangling.