The amount of objectives is hardcoded clientside last time i tried anything with it, so thats a no-no.
Amount of menus is probably overrideable, but you would have to alter other configstring indices to get it to work properly
xmodels can be shown unprecached using configstring alteration already, so no need to up that limit anyway
turrets: i dont see how anyone would need more than 32 turrets on a map, will lagg the server anyway if all those are in use. If you need more turrets, just add them to the map itself maybe?
attach: im not gonna burn my fingers on such delicate (shit) code
g_modelindex overflow is also triggered by too many trigger_use_touch, so limit those in your .map (all trigger_use_touch objects ++ the modelindex counter)
gamestate: hell no (however you can add tricks like sending precaches AFTER the client connects. Is quite hard and requires some custom coding so could be doable)
weapons: they bug out after approx 48, so increasing the limit from 64 or 128 to a higher number is useless. Just modify the weapon's parameters using the libcod functions or write some of those yourself
string length has been patched (non-libcod patch), but only internally. Still, getting to over 1024 chars and you're doing something wrong imo
cvars cause a clientside crash, so thats clientside hardcoded
headicons: hardcoded clientside (spent waaaay too long figuring that out)
statusicons: see headicons
hud elems: using over 32 hud elems is generally ill advised, but might be patchable to a higher number. havent tried.
script vars: 65k is 16bit unsigned integer, so changing that will require a MAJOR overhaul of the ENTIRE engine, so dont even go there
entity limit is 1024, but ents become invisible after 256 ents are shown (so you can add a ton of script_origins on top of visible ents), but i'd assume this is limited clientside