Standard rants:
1) Every symbolic or visual representation of a command or control flow structure in a no-code tool is isomorphic to some construct in a programming language, just more cumbersome to author and manage, especially at scale. Therefore, users of no-code tools are programmers; they engage in programming when using the tool to define some process.
2) Programming with text can be done with a variety of tools, from full-fledged IDEs to Notepad. Programming with a graphical representation can be done only with tools that render that representation (usually, proprietary tools from the no-code tool vendor).
3) Text is more amenable to being diffed, transformed, and version-controlled than are visual representations.
4) Visual representations have a low complexity threshold beyond which they simply become unmanageable. It doesn't take long to clutter the screen and make it difficult to find what you are looking for and manipulate it. Some sort of normalizing or beautifying feature for the program control graph, as well as a search feature, may be added, but these are necessarily more complicated than their text-based equivalents.
5) It's much easier to simply type in what you want the computer to do than to engage in prolonged rat wrestling to construct a representation of the procedure to be followed.
6) No-code is circumscribed: If you are writing something the no-code tool author anticipated, you will be fine, If you are writing something the no-code tool author didn't anticipate, good frigging luck.
7) We've been sold this snake oil time and time again. It was CASE tools in the 90s. In the 2000s, we were literally told that programmers would be made obsolete by the emergence of UML to program conversion tools. (I had a professor who said as much, almost in so many words.) It never takes because with the complexity of real-world software, it becomes an ergonomic nightmare.
8) No-code is intended for two main audiences: as didactic tools for children or the barest of beginners, and as production tools for dilettantes who want to program without putting in the effort or assuming the stigma that professional programmers do. In a production environment, the output of these dilettantes will be abandoned by the dilettantes themselves, who aspire to grander things like marketing, management, or finance; and will instead have to be maintained by... professional software developers, who will curse the original authors' names forever -- thus nullifying one of the touted advantages of no-code to organizations: that you get the benefits of custom programming without having to hire programmers.
In short, in order to think of things more snake-oil than no-code, I have to go to the old standbys of medical pseudoscience and multi-level marketing products. I can see no-code used as a crutch by those who are new to programming and afraid to approach it, but they would perhaps be better served by using something that involves code, but tricks them into believing that what they're doing is not programming, thus alleviating their "programming anxiety". Secretaries were successfully trained to write rather elaborate Emacs Lisp on Multics Emacs back in the 1970s -- simply because they were told that in so doing they were simply customizing their editor, not programming it!