I agree with that, and for the record i don’t think maxing out the number of signatures is the worst case in Taproot. Last time i checked 3DUP RIPEMD160 DROP RIPEMD160 DROP RIPEMD160 DROP a maximum size stack element over and over was the highest validation time per witness byte i could get. Now with the GSR there is certainly a pretty efficient way of evading the signature cache (using To @instagibbs’ point, this is only possible because the hash operations in Tapscript do not count toward the sigop budget, i think they should have.CAT), so the worst case may be to max out the 80k sigops with different signatures, and then padding the witness size using repeating hashing of a maximum size element.
EDIT: actually you can’t just create signatures with CAT like this since in Tapscript by consensus they must either be valid or the empty vector. This greatly constrains the cost an attacker can impose.