I think more important than the technical difficulty of making mIRC scripting multi-threaded is the consequence of much greater complexity for the scripter. Multi-threaded programming is a tricky beast that can often present problems for programmers with decades of experience, so I'm not sure it's suitable for what is essentially a hobby language designed to be able to be picked up and used by a layman.
If single-threaded programming was like building a house on stone, multi-threaded programming is like building a house on custard. At night. In a hurricane.
Consider all the things that scripters use that are global in scope and that we naturally assume cannot change mid-script, ie. global variables, hash tables, binary variables, files, sockets, even identifiers like $active. mIRC could reduce the problem by supporting thread-local implementations of most of those resources, but at some point most scripts will need to read or write at a global scope which means mIRC scripting would need locking mechanisms to allow a script to take control of a resource and prevent other threads from accessing it.
I'm sure some people would be happy with that and could use multi-threading to create more effective scripts. But I think for the vast majority of scripters it would just create a lot of confusion and buggy scripts. It'd certainly make mIRC scripting much harder to learn.
