>all of those reasons are solved

How does it solve the additional code complexity problem?

Which complexity? Of running a SQL query on the same database you're already using, vs writing code to support some other new system?

>Of running a SQL query on the same database you're already using

Go back and read OPs link. They create new SQL types, tables, triggers, and functions, with non-trivial and very unforgiving atomic logic. And every system that needs to read or write from this "db queue" needs to leverage specific queries. That's the complexity.

>vs writing code to support some other new system

You mean using a stable well maintained library with a clean and sensible interface to a queueing system? Yes, that is far more simple.

Not necessarily. Many languages like Java already have queuing libraries that operate on rdbms through JPA. So not even a single additional line needs to be written for this to work. We got ours working in a day and it works great. I don't know if other languages have these libraries but I'm inclined to believe they do (at least nodejs has).

Do you have to set up the triggers, tables, and procedures beforehand or how does that work?

The libraries create their own tables, triggers etc during initialization.

So your application needs privileged access (to create tables, triggers, etc) to the database in order to run? That's an anti-pattern. Your deployed application should only need least privileges possible. If you need to do extra things to your database, it should be done in migrations, which should be more privileged, but now you've decoupled the creation of these extra db objects from the library itself, meaning if the library changes, your migrations will not be in sync.

No... JPA writes out a file with the necessary DDL and the administrator runs it.

If this is insufficient for more complicated migrations, there's tooling to support it. e.g. Flyway.