To my understanding, the functionality of a <prompt> element is to define prompt audio to be played, followed by the system waiting for a user utterance. My impression comes from the VoiceXML 2.0 specification for prompts:
Conceptually, prompts are instantaneously queued for play, so interpretation proceeds until the user needs to provide an input. At this point, the prompts are played, and the system waits for user input.
Additionally, I understand the difference between a <block> and a <field> to be that:
<block> is a control item and is "not for gathering input", and<field> is an input item whose value is "gather[ed] from the user"Lastly, I know that a <prompt> can be a direct child of both a <block> and <field>.
I am pretty sure that a <prompt> collects input when inside a <field>, but what is supposed to happen when it is inside a <block>, since blocks are control items?
In the case that a <prompt> in a <block> does not collect input and only plays audio, why wouldn't you instead write the text for a prompt as content inside a <block>, omitting the <prompt>?
There is no difference.
1 - It is the field that is driving the input process, not the prompt. Try it without the prompt.
2 - If you aren't using any of the other features of the prompt element, it doesn't matter.
Note, there is something important to realize in the text you quoted. "prompts are instantaneously queued" Prompt and similar element structures just queue audio. Yes, you will usually start to hear them if there is a delay. But, the playback is separate from the element.
As far as to why you might do one over the other, it could just be development style or flow based logic. For example, when playing back data, having multiple blocks that can be jumped through to cover different scenarios might be cleaner that a complex field/prompt configuration.