Pretty much all of the examples you used of codeless tooling (drag 'n' drop programming, visual state machines and graph editors, database FK diagrams, etc) sti

Pretty much all of the examples you used of codeless tooling (drag 'n' drop programming, visual state machines and graph editors, database FK diagrams, etc) still still require an undergrad-level CS education - or considerable experience - to understand and use correctly - to that extent they're just time-saving tools that use a graphical UI to hand-wave away tedium in software development (not to denigrate them: time-saving tools and eliminating tedium is important!)- but I argue it's a disservice to everyone to let the uninitiated use these easy-to-use tools for production systems without necessary formal introduction (of course they're still a fantastic didactical aid). A great example of GUI winning over code or the command-line is a UI to allow people to arbitrarily reorder items: a drag-the-grab-handle UI is a hundred-fold better than manually entering new sort-orders for each item in a command-line array or other UI. This is, at least, the very kinds of things that visual tooling should be used for by everyone from Scratch-lang kids to SV elites. Another example you gave is of "visual interface editing" - but while you acknowledge the problems that FrontPage and Dreamweaver had decades ago, WYSIWYG is still dead, having retreated back to its origins in print-media design. The old VB6-era "drag controls from the toolbox onto the form surface" is dead because one cannot easily express any kind of non-trivial layout logic using that approach: things like CSS' flexbox, CSS grid (with auto-placement and auto-flow) and @media queries absolutely require one to grok CSS' visual formatting model, which in-turn implies someone will already be more expressive by writing CSS by hand instead of using a mouse to choose from some predefined options (I appreciate XCode's Interface Builder and constraints model is very nice and shows how it can be done right, but explaining how the constraints system works and how it should be used ends up with me having to redo the work of the designer on my team. Ugh. Another issue with visual-tooling is that unless the tooling vendor happens to control the spec that it's generating code for then the tooling will invariably and inevitably fall-behind and have limited value for more advanced users (e.g. TopStyle) - or if the tooling is meant to abstract-away multiple different backends then the tooling is doomed to support only a common denominator and won't be taken seriously by too many people (e.g. MS Word's Save-for-Web) - we've seen both of these happen with visual tooling for the web, especially with Chrome's rapid frequent releases and the everchanging spec for CSS. Web-design is now even more inaccessible as it was in the late-1990s (and is no-longer the butt of jokes: turns out the CEO's 12 year-old nephew can't apply CSS selector specificity rules - which, I note, is another angle of CSS that visual tooling just can't accommodate).