The security example is a really interesting one because what you describe as a weakness of no-code viewed another way is a huge strength.
That is, an approach of the user not understanding these things and so deliberately going for a black box, just-works-in-exactly-this-way solution that's centrally tested, audited and maintained across the no-code platform is actually pretty great for security.
Having an understanding of how these things work, even a really good one, does not preclude mistakes if you want to do things customly - on the contrary this only ever increases the surface area for mistakes.
You might argue, and it often is argued in engineering (use the auth provided by your framework, well-trusted ecosystem libraries, etc), that it's better to just rely on known good solutions even when you do have a great understanding of the principles for this reason.
I think your counterpoint is a good one — but I would argue that it has
the implicit assumption that such users will and can delegate to authority.
In my own experience this hasn’t been the case — the alternative of the user not understanding
a problem is not going with an authoritative approach, but simply not to think or care
about the problem.
Even when relying on ‘good’ solutions you need the requisite knowledge to
judge what is good — otherwise people, engineer’s included tend to view such
solutions as unnecessary. In your example, an authorization framework will
have a selection of different protocols from OAuth, Basic, LDAP and so on — all
of which are ‘good’. Without understand authorization and authentication
could you really select between them?
That is, an approach of the user not understanding these things and so deliberately going for a black box, just-works-in-exactly-this-way solution that's centrally tested, audited and maintained across the no-code platform is actually pretty great for security.
Having an understanding of how these things work, even a really good one, does not preclude mistakes if you want to do things customly - on the contrary this only ever increases the surface area for mistakes.
You might argue, and it often is argued in engineering (use the auth provided by your framework, well-trusted ecosystem libraries, etc), that it's better to just rely on known good solutions even when you do have a great understanding of the principles for this reason.