SQL persists because it's an interchange format, not just a programming language. It's one of the few programming languages you'll see embedded in other languages - and generating SQL from other languages is a common source of security bugs. You can't upgrade away from SQL without changing both ends of that connection.
You can write large programs in SQL, but it's generally considered good practice not to.
(I feel I ought to mention LINQ here, not to make any specific point but just to fanboy about it)
same, and in fact, despite using C# since before LINQ even existed, I don't even know how to write the sugar candy version of it.
Part of that is me coming from C++ and its algorithm header and the other part is that the code is just easier to read and understand than the sugar candy version (to me, atleast).
Somewhat pedantic argument: SQL is kinda dead. Sure, modern databases use upgraded dialects of it, but they are custom to each database and often incompatible with plain SQL. There are even many cases where modern databases don't support even standardized SQL constructs.
The easiest example of where databases and SQL part ways: UPSERT. It doesn't exist in standard SQL.
Then let me address the forest. Modern DBs offer SQL as an on-ramp for the most common DML and querying. This further entrenches it as a data language and why SQL just won't die.
There are always more proprietary methods where one needs them. That doesn't mean SQL is dying, it means SQL will likely grow to include some of those too.
You can write large programs in SQL, but it's generally considered good practice not to.
(I feel I ought to mention LINQ here, not to make any specific point but just to fanboy about it)