I have a few questions on this, the answers of which may help answer your question:
1. How well does having a server-side JVM work, resource-wise, when you have a forked process model like PostgreSQL? Does having the additional JVM's pose performance and competition for resources that lighter languages would not?
I don't think this is really a concern when connection pooling is used (otherwise you end up creating a new JVM per connection which is indeed problematic).
2. What is your specific use case for a trigger in Java?
The main drivers are:
Not having to learn yet another language. I find the expressiveness and readability of the other scripting languages very clunky compared to Java.
PLpgSQL is different, it is based on Ada language
Ease of porting triggers across databases. The only thing that really changes across databases is how triggers interact with input/output parameters. The main body remains the same (thanks to JDBC). This is quasi portability in the sense that the underlying SQL is itself quasi portable, but I find it a much more compelling approach than having to rewrite the triggers for each database type.
any time plpgsql will be faster then Java probably due a type compatibility with Postgres and execution as inprocess
There is a few task, that can be done in database, that will be faster in PL/Java than PL/pgSQL
