What about adding a feature that changes a fundamental assumptions of the program? Eg since the very beginning, the product has only ever supported integration with Salesforce.com, so all of the system was programmed with that assumption in mind. Unfortunately, there's now a need to support other CRMs. As support for OtherCRM is added, how sure can you be that salesforce.com support still works 100% perfectly? And then let's also add support for 30 more CRMs because that's what the customers are using. If support isn't added for those 31 CRMs, then a (high-code) competitor could come along with a better product for cheaper.
Thus, making sure every change going into the program still works with every single one of those CRMs becomes a roadblock. Not insurmountable, but at some point, the roadblock becomes an albatross around the neck of the product, making it impossible to make any changes to the product.
Having tests (hopefully automated) will make sure that the product works with all the CRMs it claims to. But the overhead of writing tests takes a non-zero amount of time/resources, which (eventually) adds up.
Please pardon my ignorance, as I've never worked in software development. Could you please explain what you mean by 'overhead', and also how a lack of testing/regressions in low-code programs would be a roadblock as the company or application scales?
As an aside, I love your analogy of code as "calcified business process". I've heard several low-code 'success stories' of business users without CS experience learning how to build apps, and they often comment that one of the most difficult things was learning to think in terms of the rigidity of code. Sometimes I ponder whether the true value of low-code platforms is simply that they teach non-coders how to think about business-level problems in terms of logical systems, rather than fluidly, which is how they experience them.