If we're reducing no-code to "things that have been written in code first, that can then be plugged together by the no-code user", then we're talking about libraries with a visual designer on top.
No-code approaches need to be prescriptive about how they deal with systems and it takes a long time to get to the point where we know how to do that in a way that won’t infuriate people.
Most of the targeted products in the space seem like they can be expressed as "I know how to ___, but I don't want to ___" (f.ex. Retool looks like: write a query, write a UI). Which, yes, trade opinionated design for design time efficiency, which is most of their value.
On the other hand, you also have no-code frameworks which are icons and a designer wrapped around primitives that afford you enough access to control flow and variables to build anything you could code. E.g. Node-RED, UiPath, or Power Automate. Which don't need to be very opinionated, because their entire purpose is to be a build-anything toolbox.
So it's probably more useful to differentiate focused no-code products from general-purpose ones.
All of which have teams of developers behind them, maintaining the code that underly those control flow constructs and form the higher level abstractions that the low code user interacts with.
What's often really going on, is often "packaged libraries" that you add to do a task, then lots of typing of sort of "glue code" in boxes to get them to work together. Which can lead to getting bit in the butt with the problems of "no code visual programming", where there is boxes on top of boxes hiding stuff and potential troubleshooting headaches.
Often, the team needs a "real programmer" or close to it, that can handle the heavy lifting, troubleshooting, or custom solutions.
I agree that "arbitrary business process" is a smaller target. But it's one that grows over time (see GP comment) to include more and more "solved problems" that were solved by lots and lots of code.
But from the GP, I read a statement on the macro scale. No-code can't codify turn-key pluggable building blocks until the problem spaces of those blocks have been thoroughly explored by code solutions, and a small number of "winning" configurations identified.
Sure, those blocks can be plugged together to prototype "novel" line of business "problems", but I think there's a disconnect in the kind of problem spaces you are talking about.
The "solved" problems that the no-code widgets represent still need to be solved by code first. And expectations continue to move.