> Why is a trigger any more surprising than any callback style interface?

A procedure call is explicit, a trigger is implicit. You don't call a trigger, it just happens as a side effect of something else. People tend to forget implicit things. Suddenly you notice that something is acting strangely or slowly in your application. You can look at your functions and procedures and try to find the problem. But if your application is full of triggers, how do you know what is going on? A trigger can change a dozen rows, which in turn can change other rows, so changing a single row can trigger thousands or millions of triggers. Also, triggers are not fired in a particular order, the database is free to change the query plan according to what it thinks is best at the moment, so triggers are not deterministic. Triggers can sometimes work and sometimes not.

In summary, triggers are implicit, have side effects and are not deterministic. They are confusing and surprising. Almost everything that can be done with a trigger can be done with a procedure, but explicitly, deterministically and in most cases even without side effects.

I don’t think there’s anything wrong with any of these features, I’ve used all of them myself at various times. The problem though is that whenever you use them, you’re introducing additional complexity to your application, so you have to decide every time whether it’s worth it. If you use these features without proper consideration, you can easily end up with a mess of interdependent schema objects. It’s easy enough to get to a state where it’s difficult to visualize code flows, and in that case making changes will become riskier because all of those features can produce major gotchas.