Obviously, with customizable variables, there are lots of settings you can change to cause lag and choppy framerates for players, by creating large numbers of particles. One particularly insidious way of doing this, though, is by setting the clip size of a weapon to some ridiculous value, like 5 million. This will immediately lock up any player who spawns with that weapon, or switches to it (unless they have /showclips 0), from attempting to draw the ammo bar: the game tries to create 5 million copies of the ammo icon, apply the correct rotation to each one, and draw it to the correct place on the screen. Of course, it will eventually complete this task, but not until at least a few minutes have passed, by which time (if it's an online game, such as Open Vars) the client has undoubtedly been disconnected for unresponsiveness. Oh, and of course the game now has to try to render the ammo bar for the next frame...
Bots don't have a HUD, so they can continue to fire the affected weapon just fine, but if a player enters to SpecTV view on a bot that's wielding it, they get the same issue before the game can even render that view.
Clearly there's an element of "tweak the variables at your own risk" here, but should there be a bit of resilience against what's essentially a DoS vector? Specifically, if a weapon gets edited to have a maximum clip size beyond a certain point (let's say 1000), the individual ammo icons are definitely too small to make out, so my idea is to cease trying to render them, and instead use the circlebar rendering code to draw the clips. In testing, with showclips 0 and showcirclebar 1, the circlebar doesn't suffer any rendering slowdown even on a 2 billion clip size, so it's a far more efficient codepath at this point where the two approaches would barely have any visible difference.