The title does not reveal that the suggestion applies only to Postgres. It is a bad idea to tie your architecture to a specific technology.
I don't think the OP intends the suggestion to apply only to Postgres:
> The name-giving PostgreSQL database is often already available and in systems where it is not, *it can be easily introduced with minimal effort.*
… i.e., don't have PG? Not a problem, just introduce it into your architecture! (/s, from me, but I think the OP is serious.)
> It is a bad idea to tie your architecture to a specific technology.
But I agree. These sort of "just keep wiring boxes together until it works" architectures cause so many headaches IME; so many pieces, each with its own failure modes and bugs. This is where I find the claim the OP makes,
> [this design, with PostgREST] is more flexible than one that is developed manually.
… dubious. No, the advantage of doing it in code I control is that I control t hat code, and if something needs to change, it can be. With wired-together-boxes-of-random-tooling like this, I have to pray my change fits into the whims of its config files.
I do think this is fairly simply for many companies.
> But I agree. These sort of "just keep wiring boxes together until it works" architectures cause so many headaches IME; so many pieces, each with its own failure modes and bugs. This is where I find the claim the OP makes,
I agree, but PostgREST is a very very simple box...
> With wired-together-boxes-of-random-tooling like this, I have to pray my change fits into the whims of its config files.
... that needs almost no configuration except the database connection string.
PostgREST, Oracle APEX, MySQL Reson.
PostgreSQL being the most popular among developers who choose this approach.