X-Perl had much of the same problems, but managed to cure it all this morning, so in the interest of fostering relations between mod authors; Here are some thoughts:
Basically got around the huge startup freeze by forcing the secure templates to startup after the first OnUpdate of a dummy frame which hides itself afterward. Had to move some things away from VARIABLES_LOADED to this new event. Very hard to nail down what the problem is exactly, but something about doing things too soon has become immensly slow.
Took a lot of trial and error with a good dose of frustration and hair pulling, and I'm not at all happy with how it's turned out. Feels very hacked atm, but it's working. With some more patience and time we can maybe identify the actual problem (or hey, Blizzard might fix it... hmm).
I can reliably replicate this problem on my warlock. The issue is minimal in the normal game world, in raids and BGs it is at its peak.
How to replicate:
Would love to see this get fixed, can't play with ag_unitframes ( atm ^^ ) and can't play without it.
This is something else that I had been blamed for with X-Perl for a while, but later we found the culprit to be Theorycraft2 which causes large pauses when pet is summoned dismissed (which also includes mounting since patch).
I'll have to look at the xperl frame code, I think they have it on a delay when it enters an instance/bg too.
Although there's been some reports that it's fixed it, I'm fairly sure it just shifts the problem somewhat and it can still fail under similar conditions.
For the curious who where asking. It just delays displaying all raid frames. Does 1 group per OnUpdate (yes, yuk, I know). Check the XPerl_Raid.lua file and look for 'displayGroup' and you'll find all the relavant code.
I'm more and more convinced it's related to memory, rather than some problem in the mods themselves.