One possible reason why users generate events into a freezing application is that they have the sense that the events are being dropped, rather than queued. This may be basic psychology. But the intuition is actually right, because badly loaded systems can in fact miss events, and I will argue below that if they are GUIs, they actually have to.
One familiar example is Firefox. When the browser is busy executing a script, then it actually loses characters if you try to type into some input fields. If you do not repeat the entry of some characters that have not appeared, they will not appear if you simply wait; they went into the bit bucket.
Queuing every event under load has downsides, because the user has no way to manage the queue. Mistakes get queued also, with unwanted results when the system gets around to servicing the events.
There are issues in queuing GUI events, which make it nonsensical to retain long queues of events. For instance, suppose we indicate to the system that I want to move a window, and then to click a button on that window, but the system is slow, and so these events do not actually happen until later. When the events are processed, should the click be referenced to the moved window? Or should the click be referenced to what was displayed under the cursor at the time the click was issued? The proper solution to the ambiguity is to drop the click event.
So:
sensibly designed graphical interfaces have to drop events suck as clicks when the system is unresponsive, because delayed processing of queued events will lead to chaos. this means that if a click does nothing, it has been dropped into the proverbial bit bucket, and the action as to be repeated in order to take place. users are not provided with adequate feedback which indicates the system's readiness to handle an event such as a click: the only way to know whether an event will be accepted is to try it. (Though some user interfaces change to special cursors, or gray out parts of the UI, etc to indicate nonresponsiveness.) therefore, users repeatedly click until a response occurs: rational behavior.The real question is: Why do people click rapidly when an application has given clear feedback, such as a spinning hourglass cursor, or greyed-out window, that it is not currently accepting events.
This could be a combination of multiple factors. One is the basic instinct to just prod at something that doesn't respond, as if it were a living thing that needs to "wake up". It may be part learned behavior, from having used systems that do not have such a clear indication. It may also stem from not fully understanding the indication that the application is busy, or from the belief that clicking does in fact help. (The hypothesis that clicking helps cannot easily be disproved; there is no way that the user can be certain that the application would have recovered from that particular situation just as quickly without their rapid clicking efforts.) In fact, those users might be right: the operating system scheduler can take into account the user's impatience (measured by their clicks), and arrange to give more priority to the user interface tasks! And if it does not, perhaps it should! Furthermore, applications should be written so that all lengthy tasks are modeled as background process that allows the UI to remain responsive, and not as being in the same event processing thread so that the UI blocks.