Hello, 

I believe the main reason was to avoid infinite loop. Starting a Declare Trigger based on a specific commit and then commit inside said trigger.

The Declare Trigger is being fired in response to a "primary" save, delete or commit event. For save and delete, these would need to be confirmed with a subsequent commit anyway - usually orchestrated by Pega's flow processing or queue processing. At that point, the deferred saves/deletes from the Declare Trigger are also committed. 

The risky scenario is for a Declare Trigger firing on deferred save or deferred delete. These deferred actions can be cancelled or rolled back. If your Declare Trigger has committed something else before Pega deems it should roll back the main save/delete, your data integrity is compromised as this won't be rolled back. 

Continue to allow the main processing sequence to orchestrate commits and rollbacks. If your Declare Triggers are creating other data items, let them be committed at the same time everything else is, or be rolled back if the orchestrating process requires that to happen.