AppleEvents can be sent to applications running on other systems. Versions of MacOS prior to MacOSX were not exactly pre-emptively multi-tasking, and so invoking something that might block (because the other application on the other system crashed or what not) indefinitely was something that needed to be dealt with. So they made it such that AppleEvents would time out after some fixed amount of time. As a side effect, for DisplayDialog, if the user took too long to respond, the AppleEvent would time out.

To get around these problems of AppleEvents timing out, if the response was something that the AppleScript really didn't care about (such as from a remote system for an application would respond to the event by presenting a UserInterface to its local user), it could surround the invocation of the command that involved the possible timeout with ignoring application responses and end ignoring.

However, if it was something that involved a DisplayDialog and the response was really desired, there was only one solution before the advent of AppleScriptStudio: instead of invoking the DisplayDialog, merely have the ScriptEditor open up a script that started with the DisplayDialog. This way, when the user was ready, they could run the script, get the dialog, and respond to it.

After the advent of AppleScriptStudio, another option presented itself: create an application that had a window with a button on it and clicking the button would cause the AppleScript that had used the DisplayDialog to run. But if one is already in AppleScriptStudio, one doesn't even need to run DisplayDialog - one only needs to read the fields that one has put into the window and such.