A Send Task is a more specific type of Service task from the semantics perspective. On the implementation level, both have the same behavior [1].
A Receive Task will wait for an BPMN message in the engine. You will need an external service which correlates emails to the processes an triggers messages. [2, 3]
As for the example, the poll pizza orders has to be a service task as it actively checks the mail. For the send Tasks, it does not matter because it’s the same behavior.
Unfortunately I don’t know the answer you with your last question but I hope I could help you anyways
Why it has to be service task? Send task implementation also same as service task,so we could’ve used send task instead of service task and it will be a clear picture for what’s happening in the process flow.
In this specific case the Task polls and stores the emails in a process variable that are available at the start of the process. We can’t use a Receive Task for this because the semantics of a receive task is to wait for a BPMN message (not an email) and continue with the process after it was received. A Receive Task does not implement any business logic.
Send Tasks and Service Tasks have more or less identical execution semantics.
But their visual differences are important.
For good practice a company might decide to use a Send Task only to indicate communication over network. This could help users when reading the model to understand when communication with other systems happen. When a Service task may simply indicate the execution of “local” code, like Java Classes.
But this is all considered to be a best practice approach rather than hard and fast rules.