Triggers have one or two good use cases, and plenty of bad use cases.
I would suggest the strongest use case is for data validation. Databases don't have very sophisticated type systems, and custom data types can cause headaches. Database triggers allow you to ensure that the data stored in fields matches a set of criteria. To give a basic example, if you had a customer table with an email address field, you could validate that the email address had an @ symbol using a code in an insert and/or update trigger. Of course, you should have similar checks within the software that sits on top of a database, but by putting the validation at a low level by using database triggers you can be more confident that the data integrity will be protected.
As a second use case, if the triggers are being used to maintain data for audit or reporting purposes, that can be fine.
However, aside from the audit/reporting use case, I would recommend avoiding using triggers which span multiple tables (unless there are some exceptional circumstances where it's the best option). Things get messy when you have a chain of tables, each with their own triggers that can update other tables within that chain. If you spot lots of code like that, run to the hills!
(Such triggers of course are removed once the application is updated, along with any old schema bits.)
You setup your preconditions, you execute any action, you assert your post condition. You can use something like http://pgtap.org/documentation.html to write your database tests.
Triggers have a place in app development, and sometimes are the best things to use.
One of the major use cases of serverless functions is as triggers.