When I'm on sch (since I happen to be set up for that already), casting Cure III with <stal> causes a 1 second dip to 24.6 fps (almost always exactly that value), then it's back to 29.5. Casting Cure II with <stpc> causes a dip to 21.3-24.0 fps before reverting. Overall, a delay of about 150-250 milliseconds (ms).
There are two areas that that delay can draw from: the rules, and equipping the gear. If I go in and comment out all the gear that could be equipped for curing, such that it only equips empty sets, fps after the above uses are 24.3 for Cure III and 22.8 for Cure II. So it's not the actual act of equipping the sets that's causing the fps lag.
As mentioned, use of "input /ma cure3 motenten" from the console causes no fps lag at all, but entry from the chat line drops fps to 24.7. That implies that it's not the Spellcast rules that's causing the lag, since the same rules run regardless of input method.
To validate that, I put a <return /> at the very top of the rules section, so that nothing would get run. With the return rule in place, there was no lag. Therefore it -is- somehow related to the rules.
Going back to the console aspect, tried using "/console input /ma cure3 motenten" from the chat input line; this caused no lag. So it's not merely the fact that it's coming from the chat input that's causing lag.
Then I tried something else: "//cure3 motenten" caused no lag, but "/ma cure3 motenten" did cause lag. I'm guessing the "//" shortcut evaluates to "/console input".
"//cure3 <stpc>" also causes lag, as it's being injected back into the main game thread in order to do the target selection.
My best guess right now as to why the console version of the commands doesn't cause the lag is that it's a threading issue. Anything going through the console (even if the text originated on the chat line) has to be on a separate thread, otherwise opening the console would completely stall the game. However it appears that when Spellcast is interacting with direct input from the game (particularly with <st*> type selections), it's running on the game's main thread, and thus liable to stall the game due to long processing.
Essentially, Spellcast is sitting between the user chat line input and the text being sent to the game. /console commands are handled by Windower itself, pulling it completely out of the game thread and thus not interfering with the game directly. Use of Spellcast then happens on the console thread, and is then injected back into the main game thread, so no lag. Regular commands stay inside the game thread, though, which means every bit of the delay is felt in the game environment.
Of course a better solution would be for the Spellcast processing to not take so long in the first place. Unfortunately I'm not sure what else I can get rid of without gutting large parts of the functionality. The whm xml has already been simplified similarly to the sch xml; both have been streamlined to remove almost all BaseSets, to minimize the amount of time spent searching through the set lists.
Honestly, I'm just desperately waiting for the 3.0 release, hoping that it will fix a lot of the inefficiencies of the current version of Spellcast. Was hoping it'd be out by now.