I was pretty young back then but I do remember a lot of these things being driving forces behind 4GL and 5GL languages. I played with a lot of these things because I was just getting into programming and I was still at the "syntax is hard, maybe what I need is a simpler language" phase...

A lot of these things failed for reasons that are, I think, fundamentally unavoidable if your goal is to not learn anything and just do it:

- Tools that emphasize (or function exclusively based on) configuration over over code are limited by things that you can configure. As soon as you stray beyond that, you not only have to code, but you have to code for a system that has a lot of implicit behaviour. That's a hellish experience if you're an inexperienced programmer. Figuring out why your code produces a result other than what you expected is hard enough. Figuring out why your code produces a result other than what you expected because there's a default configuration flag that alters its behaviour (or, worse, that alters the result after your code correctly computes it) is way more complicated.

- Tracking changes in systems that emphasize (or function exclusively based on) configuration over code is insanely difficult, and reverting systems back to a specific state is pretty hard, too. This may be less of a problem today, in the age of containers, I guess.

- Validating changes in such systems is even more difficult than that, because a lot of the logic is implicit and hidden from sight. If you have to make a change in a system you're not too familiar with, reading the code can give you an idea about what behaviour would be affected. If your change breaks something, reading the code can help you debug things. If there's no code to read, or you can't do it in the first place, and changing the header of a column just broke your reporting tool, you're going to spend a few fun evenings at the office poking it with a stick until it un-breaks.

- Tools that emphasize integration of separate tools over coding result in systems that aren't very fun to maintain. Changes in the way components interface were a problem even in the early 00s, and they weren't on a rolling/continuous release schedule, weren't delivered "as a service", and "move fast and break things" was just called being sloppy. Integrating a dozen third-party modules today requires full-time maintenance, from someone who can definitely code.

I do think that making it possible for end-users to automate their work is a direction worth pursuing, but this isn't the way to do it, and I think there's a wealth of lessons from two decades of failures to learn.

IMHO, some broad directions worth pursuing would be:

- A simpler and more stable development framework. Keeping up with JS and CSS frameworks (many of which exist precisely because pure JS and CSS are pretty painful to use if you want to develop a desktop-like application) is hard even for people who use them professionally. There's no way you can ask business people to keep up with that. A more stable framework, that hides the fact that browsers were never meant for application development well enough (even if that means less flexibility) could go a long way towards making things easier.

- Better DSL integration in business tools. A lot of the business logic is written in the same language as, and embedded in, the overall application logic. That doesn't necessarily have to be the case. Template engines are sufficiently advanced today that you can do a lot with them, and I've seen people without much programming knowledge being able to use them productively.

- Oh and if we're being honest: better code quality where code really can't be eschewed. Virtually every business app I've seen in the last ten years is the same story: a user needs a change, they can articulate it perfectly well, they can describe the logic in pretty good details, sometimes they can even give you an Excel sheet that implements it so that you can see a few examples. The only reason why they can't make the change themselves is that sorting a table by date instead of name doesn't involve replacing SORT_BY_DATE with SORT_BY_NAME in a template, it involves changing half a dozen SQL queries, two hardcoded parameters in some JS function calls, and introduces a subtle bug because passing SORT_BY_DATE in that function call actually modifies the table in place, which is a global variable, and that table is then reused by another function which assumes it's sorted by name.