Also the 100ms of latency is a limitation of JDBC, not of using Postgres. Note the complete lack of sleeping in the python sample code.
That depends on your app size. If you're building something relatively small then having a few additional DB connections vs a dedicated MQ server can be worth it (it's really just extra shared memory for the connection). I do agree though that most folks are better off just using a real MQ server. For anything larger (both app size and app scale) it ends up being much better.
> ... the best way to use this pattern is to have a single server listening to PG notifications and publish them to a real MQ.
Another approach I've been looking at is creating a writable FDW[1] that bridges to an MQ system. That combined with a PG background worker[2] to listen for notifications gives you a transactional system that starts/stop with your database.
[1]: http://wiki.postgresql.org/wiki/Foreign_data_wrappers
[2]: http://www.postgresql.org/docs/9.3/static/bgworker.html
Yeah, JDBC has no provision for asynchronous notification. The alternative is to create/use libpq bindings directly.