We have those already. They're called IDEs. It turns out there's only so much complexity you can hide if you need to describe what you want to do unambiguously enough to be executed by a machine. Something like Visual Basic is probably as far as you can bury complexity while still being widely useful. Go much further and you start to drastically constrain the range of apps that can be built with your app-building-app.
SQL is just the lowest-common-denominator notation for accessing and manipulating data by performing operations that can be represented by relational algebra and relational calculus. Fixating on the language itself misses the point that there is a theoretical underpinning to why data is handled this was in many practical applications.
I think it's mostly that Salesforce was founded by an Oracle executive (and is just generally a bastion of enterprise software mess).
The reality is that you still have to model some specific domain against which SQL queries can be written. I 100% agree with doing implementations in SQL, but you still need imperative code wiring your well-normalized interpretation of the matrix into the outside world.
That said, SQL is more powerful than most developers are aware. Using providers like SQLite allows authoring UDFs which blur the lines between code and SQL. The nastiest bits of our product are implemented by business owners in SQL now. We have written UDFs like format_date() which are simply thin wrappers for things like Datetime in C#. Developers just ensure stability of the schema/UDFs and any relevant Code-to-sql mappers. Also note the in-memory mode of operation for SQLite makes it a perfect fit for large numbers of ad-hoc projections in parallel.
...which is interesting, right? SQL won. There are no competitors. Everybody uses SQL. But if you ask developers how they develop their interfaces, you'll get a million answers, ranging from DOS terminals, Electron apps, PWAs, .NET forms, whatever. Maybe what we need is SQL for the view layer to complement the relational backend? SQL is famously easy to pick up because it allows the user to describe what they want, not how to get it. React and friends get us closer to this goal of universal reactive programming, but nothing/nobody has capitalized on providing an all-in-one "put words in this box and get what you want" type application. I guess the assumption is that building such a language is functionally impossible, but I really wonder if that's true. The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process.