I can't reproduce what you're seeing.
I cannot reproduce this either. However, different versions of Windows behave differently in this context.
Since the confirm exit dialog is being displayed, this means that Windows is using a SendMessage() to trigger WM_CLOSE. However, mIRC uses asynchronous messages to exit, which is why it needs to wait for the script to finish.
If I recall correctly, the exit method used to use synchronous messages to force an immediate close but this had a number of side-effects, including issues relating to scripts, COMs/DLLs, and so on. It was eventually changed to use a slow, asynchronous exit to allow scripts to finish normally.
It is difficult to remember the rational behind all of these decisions because there have been so many changes to the exit method but looking at the code, the script parser has a check for a global exit flag but it has been commented out. My guess is that there was a decision to allow scripts to complete normally during an exit, instead of halting them in the middle of a run.
mIRC does set $exiting, so any script that does take a long time to process can detect whether a user or windows has requested an exit, which allows the script to halt safely without leaving behind corrupted files/data/etc. However, a badly written script, such as one that uses an infinite loop, will simply persist, and mIRC can then only be closed forcefully by Windows.
