Point of low code is to get rid of those smart ass developers who know those magic incantations and demand loads of money for their work.
What you get in low code reality are smart ass business consultants that know magic configuration options and demand loads of money for their work.
Just look at SAP, Salesforce etc.
From my point of view any barrier to entry doesn't matter because at some level you just trade one complexity for the other.
For non complex stuff excel works fine and low code is not advertised as alternative to excel.
Doing anything nontrivial in SAP and Salesforce also requires coding, only now you're doing it in proprietary scripting environments like ABAP and Apex respectively instead of general languages like Java and Python.
Presumably we would agree that writing a web app is more economical in Python, Ruby, Go, etc than in C or ASM. Both C devs and HLL (higher level language) devs are well-paid and well-versed in their tool set. The difference is that HLL devs can deliver value at a higher rate than C devs for this domain.
If we can agree on the above, then presumably it's conceivable that the same abstraction principle applies with low code solutions--yes, low code users will know their tool well and earn loads of money, but they will probably move faster than traditional programmers for this domain.
In my mind, this only holds as long as these low-code tools are really more abstract and not just a visual/graphical programming language (I'm sure there are very low-level visual programming tools that would allow you to manage your own memory, etc). It also depends on the domain being amenable to abstraction--if you have to drop out of the tool with some regularity to do things the tool doesn't support (e.g., performance, custom analytics, etc), there's a threshold at which the overhead of calling into a lower level language exceeds the benefits of the tool. I don't know where this threshold is, largely because the domain isn't well defined.
But I do think low code solutions are conceivable for certain domains. I would make the argument that Microsoft Access and Excel either qualify as "low code" solutions or they are at least proto-low-code solutions, and they both deliver tremendous value. I would perhaps even say that Access/Excel are to client-side applications what these new low-code solutions are to web applications. Not a perfect analogy, but I think there's something insightful in there.
There is nothing "low code" about work in SAP. Any time you need something remotely custom you need to blow the dust off of ABAP and code it yourself. This happens a lot.
Salesforce even requires you go write up some Apex when you want to get into heavy customization.
Now take a look at honeycode templates, those look exactly like things that SAP and friends promise you won't have to code. Inventory management and customer tracker, this looks like they try to sell the same things. Even if SAP is not marketing their stuff as low code or even if you have to write a lot of code there.
What you get in low code reality are smart ass business consultants that know magic configuration options and demand loads of money for their work.
Just look at SAP, Salesforce etc. From my point of view any barrier to entry doesn't matter because at some level you just trade one complexity for the other.
For non complex stuff excel works fine and low code is not advertised as alternative to excel.