A lot nocode or lowcode tools are visual programming languages; they are in fact just programming tools but look (and often are) simpler to start off with. But when you need more, you are in fact programming with code, just via a visual interface. Which indeed can (will) become painful for many tasks. Then you are using the wrong tool for the job.
Thing is, and this differs per market; most companies do not need anything more than endless streams of crud apps, and that is where these tools shine. You (and many of HN) might work in the b2c market, but where I work, people do not care much about how things look or ux; they care if they work just a little better than the sap or oracle interfaces they had before. Actually, this goes for many (most?) b2c products as well; most (traditional; challenger banks are a lot better) banking or airline apps I know look like bad template barf-ups (many are indeed that, bought from the same cooking cutting companies) and yet people use them. Would it be better if they were custom designed with money spent on actual ux and design? Sure, but apparently not enough to matter to the company commissioning it.
When companies I work with look for no/low code, the only reason they will not use it is vendor lock in; if they cannot run on premise and/or ‘eject’ the code, they will not use it. Several products allow this and they are fairly popular (so much in fact that they cannot find enough ‘devs’ for their clients).
These systems have their place; it is just (much) faster (some boring things in regular environments are just a few clicks with these tools) for some x% of applications while another y% you cannot do with them or is very difficult; I would still do the x% in such a tool as thinking ‘we might need x+y later on’ is premature usually and in my experience does not pan out. We have programmed applications ‘created for expansion’ 15-20 years ago that run to this day which would have fit in the x%; aka we wasted time and money while the expansion was never realised by the client.
Edit;
> it would imply the supply of apps competing for that category would explode.
And that is a very consumer centric approach; we are not all making fitness apps or something; these apps would all look (more or less) the same but work on different APIs and data; that is fine for almost everything; not only some internal stuff. It helps companies a great deal to just have something their clients can use vs nothing, even if the cost is close to zero; and they cannot be the same as they talk with different systems and different data. Even creating partner dashboards more efficiently than slinging code is something people do all the time and you cannot ‘just copy paste that’ to another company.
These products are not generally meant to build ‘the next whatsapp’. But you can prototype it with them and show investors; I agree with you there though; wrong tool for the job.