The timing here is quite complex since it also depends on which operator arrives at the passover point first. You can see this when you change the position of the queues. If Operator2 arrives first, the delay task will also not work.
Another thing is that the task activities can be throught of as two steps, creating the task and executing the task.
Here is what I believe the ordering to be:
Delay Task - Operator1 arrives first:
Delay Task is generated -> Load Task is generated -> Delay Task starts -> Load starts -> Delay Task Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1
Delay Task - Operator2 arrives first:
Load Task is generated -> Delay Task is generated -> Load starts -> Delay Task starts -> Load Task Ends -> Delay Task Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while no item is still held by Operator1
General Delay - Operator1 arrives first:
Delay Starts -> Load Task is generated -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1
General Delay - Operator2 arrives first:
Load Task is generated -> Delay Starts -> Load starts -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while item is still held by Operator1
Compare this to using a Move Object activity in place of the Load activity:
Delay Starts -> Items are moved in an instand -> Delay Ends -> Task Sequence of Operator1 Ends and the new one starts -> Travel Task is generated while no item is still held by Operator1
You can see all this for yourself by stopping the model and stepping through it one event at a time. You will see difference of which token advances first.
In summary: Sometimes activities/tasks actually consist of multiple actions that each take 0s. A 0s Breathe will only delay the token until all other currently pending events at that time have finished. If a new event is created after the delay starts, the delay will finish first.
In those instances I personally then often use delays with a finite time (like 0.0001s) (calling them 'Long Breathe' to be able to see the resulting timing at a glance).