Not really. The comparison here is one regex vs. many, so we can assume the actual lookup of each individual regex will correlate with a combined regex, ex:
m/match1/, m/match2/ and m/match3/
vs.
m/match1|match2|match3/
The lookup times for each individual regex in the first list should sum up to *about* the lookup time for the final match. The only potential difference would be in the efficiency of the final combined DFA algorithm used by the regex library. However efficiency is unlikely to be the limiting factor, as most regex libraries are highly efficient at combining DFA's.
The important point to note, however, is that this does not consider the compile time cost overhead for compiling a regular expression into the DFA. It's likely that the overhead of compiling three separate expressions will outweigh that of compiling one, since in this case its complexity is only the summation of the individual expression complexities (plus any delta in the efficiency as noted above). This also does not include *significant* overhead in the mIRC parser itself to actually parse out three $regex identifiers and send it through the interpreter.
I would purport that for any %s, the overhead of "$regex(%s, /a/) $regex(%s, /b/) $regex(%s, /c/) ..." will likely overshadow that of $regex(%s, /a|b|c|.../) and eventually incur a significantly larger execution time for some N $regex's, regardless of the matches or string values in question. The "N" value itself, would depend on the complexity of the matches used, but not the string value %s. If all the matches are string literals (like a|b|c|...), the N value should be very low.
