You're right in a broad sense and wrong in a somewhat subtle one. A major part of the value add of any programming language is what it does not let you express.

If you move from asm to C, suddenly goto is stuck within a single function and calling conventions are absurdly constrained. If you move further up the stack goto might be removed entirely and function calls might throw an exception if the calling convention is violated. People like this restriction.

CPython has id() to get the address of a value. Really convenient. Totally messes up alternative implementations of the language. Other languages won't let you talk about the address of a variable at all.

Removing capability from the programmer helps communication with other programmers, simplifies parts of the implementation, sometimes simplifies writing programs in the subset that remains.

Working in a non-turing complete language can give you hard guarantees on termination. If you go as far as regular languages, function equality is decidable. As in convert to a DFA, minimise it and alpha-rename, and the two functions compute the same result iff said DFAs are definitionally equal. You don't get that with a general purpose language.

Regardless, I share your irritation with low code systems to the extent I've tried to do things with them so far. An escape hatch to java is really not a thing I want. A wholly general purpose Turing complete graphical programming system sounds awful to me.

That doesn't make the fundamental premise of a heavily restricted language with a weird interface wrong though. All programming languages are more or less heavily restricted already, and a bunch of them have weird interfaces.

I believe low code style systems are the right things to program some applications in for much the same reasons that config languages shouldn't be Turing complete.

Less clear is whether any of the current low code tools (other than Excel anyway) deliver on that optimistic view.