Well, you can write stored procedures in JS/Perl/Python for Postgres, but not necessarily for other databases. And if you do it's probably not portable. And the fact that this capability exists I think is some evidence that sometimes you can't do enough with SQL to do everything you need in SQL.
Anyway, I was talking in generalities, not about Postgres specifically. I would argue that if you're going to use Python to write stored procedures, why not just write a traditional Python script/app with SQLAlchemy? That SQLAlchemy has an ORM capability doesn't mean it needs to be used that way, as it's creator takes pains to point out. And this is a much more common pattern for using Python with a database, which is to my original point that its easier for most people to do.
python for stored procedures: bring code to the data, not data to the code, i.e. it's much much faster because there is no overhead for shuffling data over the network, a few serializing steps and everything in between.
It's much more probable that you will switch your language/framework then changing the database. This fear of "database lock-in" is unreasonable and the source of many not so good patterns ( as in ORM :) ). The only reasonable rationale for fear of lock-in is Oracle :) but you again, it's unreasonable, and you even semi-automated processes for migrating https://aws.amazon.com/dms/
Anyway, I was talking in generalities, not about Postgres specifically. I would argue that if you're going to use Python to write stored procedures, why not just write a traditional Python script/app with SQLAlchemy? That SQLAlchemy has an ORM capability doesn't mean it needs to be used that way, as it's creator takes pains to point out. And this is a much more common pattern for using Python with a database, which is to my original point that its easier for most people to do.