That might be reasonable, but I don’t think it’s good enough: there’s a difference between “you can waste X resources doing this silly pattern that serves no purpose except as an attack” and “you can now waste X resources with arbitrary logic”. In the former case, you’re only vulnerable to deliberate attackers; the latter case you’re vulnerable to everyone who comes up with new logic they want to deploy. It was easy to make 4MB blocks as soon as segwit was active; but until inscriptions came along, there was no real reason to do that. We don’t want to have GSR result in a similar state change from “it’s possible to make slow blocks” to “it’s profitable to make slow blocks”, if you see what I mean.
Limiting the worst case GSR execution costs to the equivalent of a block full of fairly normal transactions would be very safe, by contrast. I think that would be something on the order of ~13k signature operations per block rather than 80k (based on filling a block with ~3300 2-in, 2-out 2-of-3 multisig p2wsh transactions).
Targeting a validation time of perhaps one or two microseconds per vbyte (so one or two seconds per block) or so would be a better target, I think, though obviously that would require picking some baseline hardware as a minimum standard.
Restricting existing script functionality is a different discussion, definitely, because it potentially confiscates coins. It can still be worth having that discussion, either because we might be able to design restrictions that are only likely to restrict attacks (cf BIP 54), or because we might be able to figure out other improvements to avoid the need to restrict things at all (eg PR#16902 or CVS-2025-46598).
But the easiest chance we have to do better is when introducing new functionality, so if we’ve got a better means of analysing the potential costs (which the varops budgets is!) then also thinking about the limits from a fundamental perspective rather than just cargo culting what we’ve had in the past.