The benefit and problem with triggers are two sides of one coin. Once defined they will always be executed. This means future application code will always have notifications baked in and the programmer, no matter how new, will not forget to add it. Conversely some future requirement that does not need notification cannot avoid it. You know your application best. Which of these seems most problematic or beneficial in the context of your team and business?
Supposing the notification uses only values from the data row and no further information from the application, implementing as a trigger will save a network round-trip from application to DB server.
In my experience triggers are often forgotten about during debugging. People only look at the application code. Triggers cop the blame for much "magic" that happens out of sight.
A happy compromise is stored procedures. They can perform several actions from a single network message and all actions are in plain sight. The code is easy to put under source control, just like all other application logic. Should future requirements make notifications conditional that can be added to the SP and still have visibility.