The issue with stuff like SQL/JRT is that often stored procs are just running a few SQL statements in a row, the stored procs are being used for security or latency optimization but not because there's some truly complex logic. And if you want a language that has the basics like variables, loops, conditionals, data structures etc but which also makes issuing SQL statements natural, then it's hard to beat PL/SQL.
I really mean that, all those approaches using Perl, Java, .NET as stored procedures never gained much love among DBAs or the market in general, and I always favour approaches where I am not the only person on the building that can change something.
Also those approaches lack the end to end tooling, so you're basically back at printf debugging.
This is actually quite relevant to language design, too many people still get lost on discussing about grammar and language semantics, forgeting about everything else that is quite relevant why chose language A over language B.
Transact SQL is a close second, thanks to the tooling, but not as great as language, still better than the alternatives.
pgSQL has the plus of being similar to PL/SQL, but it is neither as feature rich, nor in tooling.
Everything else is even worse.