Fabiano Amorim lays out an argument:
By default, SQL Server executes both DML (data manipulation language) and DDL (data definition language) triggers under the security context of the user whose statement causes the trigger to fire. The trigger author supplies the code, but the future caller supplies the privileges under which that code runs.
This is the default behavior of SQL Server triggers, and it creates a dangerous situation. One principal controls the trigger code, another supplies the execution privileges and, combined, the trigger can then potentially hijack the caller’s authority.
Additionally, a user who creates a trigger does not need permission to perform every operation contained in the trigger. They only need permission to create the trigger – and then an opportunity for a more privileged principal to fire it later.
Click through to see how things can go wrong and what alternatives would be possible for a new execution model.