Additional costs would be in terms of A) chance of user error/application error -- proposed method is much simpler, as well as extra bytes for control flow ( 4 per script if I am counting right).
The costs on a normal script do seem slightly more friendly, except this method allows for hidden-till-spent permission groups, as well as as smaller blockchain bloat overall (if scriptSig script has to store the logic for all the potential permission group, it will be a larger script versus only needing one permission group's script). An added benefit could also be in blockchain analysis -- you can actively monitor the utxo pool for your known associated scripts, whereas you couldn't for specialty scripts assembled per group. Enables repeated spends with groups as a "cost object" w/o having to recall all participants. ie, pay to the same perm groups as the other employee did last time, but include me as a root this time.
Do you have a transcript of that chat by any chance? An interesting way to do that would be to push the sigs onto the stack & have implicit orders, then do expressions with their aliases, and then be able to assign "spending groups".
ex:
code_sep
push script0
push script1
push script2
push script3
group_sep
mkgroup_2, 0,1 ; the id will be 4
mkgroup_3, 0,2,3 ; the id will be 5
mkUnionGroup_2, 4,5 ; the id will be 6
2_of_3_group 0, 1, 2
mkIntersectionGroup_2 5, 6
complement_last ; complements last group, mutation
del_group 1 ; deletes the group #1, groups then reindex after deletion (maybe the group was useful base class).
etc...
multisig check perm groups (checks if any groups on stack are valid from script)
or even something like adding a little SAT scripting language with an eval.
push script0
push script1
push script2
push script3
push <a=(1 & 2 & 0), b=a-1, a | 3 | b >
eval