The Triggers create event subscriptions that are 'permanent', not dynamic. Irrespective of what the rule's actions do, these subscriptions remain active, and consequently the rule can be triggered at any time, even while it is already running (possibly during a delay).
Waits create event subscriptions on the fly when encountered in the actions. Once the Wait fires, when it is fulfilled, these subscriptions are removed. When such a subscription is for the same device as used in a Trigger, there are two active subscriptions simultaneously, pointing to two different methods. Both will fire, and this can and does create a race condition (which may possibly be benign). The handler for the Trigger event is going to cancel the Wait, and remove its subscription along with that cancellation. However, the subscription for the Wait may have already fired, so it's too late. So, two instances of the rule are running simultaneously, one from the beginning due to the Trigger, and one after the Wait. This needs to be thought through very carefully.
Triggers always cancel pending Waits. But, overlapped use of subscriptions leads to issues.