In an CS game, the number of variables you can have is limited by the amount of memory your browser is willing to allocate on your behalf. Where the space comes from is dependent on how your browser is implemented–some browsers might use only RAM, though I think most of them use disk space too as needed for temporary memory for application data that is not in immediate use.
Since these CS objects are basically nothing more than a different way to access certain variables, the memory they use is similar to what you’d use if you set up all your variables without using the objects. Consider that you had three characters in your game, and each of them had four stats, and those were the only variables you were using in your game. Your stats array in mygames.js might look like this:
stats = {
name1: "Joe"
,sex1: "male"
,strength1: 50
,health1: 50
,name2: "Jane"
,sex2: "female"
,strength2: 50
,health2: 50
,name3: "Harry"
,sex3: "male"
,strength3: 25
,health3: 75
};
If you used CS objects for this, you’d have three objects, each with four elements: name, sex, strength, and health. Then you’d have four element variables with the same names. None of these are defined in the JS stats array. So the stats array would look like this:
stats = {};
In your CS code, you’d have the following instructions to define your object type:
*define_object_type character c_name c_sex c_strength c_heatlh
The above instruction allocates some overhead space for the object type definition and for the four “element variables”: c_name, c_sex, c_strength, and c_health.
Then you would create your three objects and assign values to their elements:
*create_object char1 character
*create_object char2 character
*create_object char3 character
*set_all_elems char1 "Joe" "male" 50 50
*set_all_elems char2 "Jane" "female" 50 50
*set_all_elems char3 "Harry" "male" 25 75
This creates objects char1, char2, and char3 all of the defined object type “character” as was defined in the *define_object_type instruction and assigns the same values to them as was used in the regular CS approach. This allocates a little overhead space for a reference to each of the objects. It also allocates space for four elements per object, but this is not overhead space, this is the space your original variables would have used anyway. That is, in the normal CS approach, your “name1” variable is equivalent to the “c_name” element in the “char1” object. The “health3” variable is equivalent to the “c_health” element in the “char3” object.
If you decided to add a fourth character, compare what would happen in the two different ways of doing things. In the normal CS approach, you’d be adding name4, sex4, strength4, and health4 to your stats array. In the CS object approach, you’d call \*create_object char4 character and then \*set_all_elems char4 "Sally" "female" 25 75. You create the overhead of the additional object reference, but your four elements still take up the same space as the four normal CS variables would use.
So in this scenario, you have the object model approach using some amount of overhead space (depending on the number of elements you declare) for the object type definition. You also use 25% additional space per object: Four elements take the same space the four variables normally would, but you have an additional object reference. Four-plus-one is a 25% increase. If you had more elements in the object, this percentage would go down. For instance, if you had 10 elements per object, ten-plus-one would be a 10% increase.
There is also the possibility of saving space by using objects. Suppose each character could have a weapon, and each weapon has a name, damage rating, and ammo capacity. Each character would also need to have a current ammo count. So the normal CS approach might look like this in the mygames.js file, assuming just three characters:
stats = {
name1: "Joe"
,sex1: "male"
,strength1: 50
,health1: 50
,weapon1: "pistol"
,damage1: 5
,capacity1: 6
,ammo1: 3 // how much ammo is remaining to this character
,name2: "Jane"
,sex2: "female"
,strength2: 50
,health2: 50
,weapon2: "pistol"
,damage2: 5
,capacity2: 6
,ammo2: 6
,name3: "Harry"
,sex3: "male"
,strength3: 25
,health3: 75
,weapon3: "crossbow"
,damage1: 10
,capacity1: 1
,ammo1: 20
};
You’ve added twelve new variables to the stats array. Using objects, you’d have something like this:
*define_object_type weapon w_name w_damage w_capacity
*define_object_type character c_name c_sex c_strength c_heatlh c_weapon_ref c_ammo
*create_object wpn1 "pistol" 5 6
*create_object wpn2 "crossbow" 10 1
*create_object char1 character
*create_object char2 character
*create_object char3 character
*set_all_elems char1 "Joe" "male" 50 50 "wpn1" 3
*set_all_elems char2 "Jane" "female" 50 50 "wpn1" 6
*set_all_elems char3 "Harry" "male" 25 75 "wpn2" 20
Since Joe and Jane are both using the same type of weapon, a pistol, they both have a reference to wpn1. This saves having to store the information about a pistol twice–once for Joe and once for Jane–like you’d be doing in the regular CS “tons of variables” approach.
If we decided to add Sally to the above mix, we’d have eight new CS variables for her in the normal CS variable approach, but in the object approach, we’d have these two additional lines:
*create_object char4 character
*set_all_elems char4 "Sally" "female" 25 75 "wpn2" 15
The above indicates that Sally is carrying a crossbow and 15 crossbow bolts. We also know from the wpn2 object that a crossbow deals 10 damage and has a capacity of 1 shot, but we don’t have to carry that info around with Sally.
You could, of course, do some magic with *setref and {var} to do something similar to what objects allow you to do, but that would actually incur overhead similar to what the object approach does, and is so damn difficult to read and maintain imo .That’s one of the reasons I implemented objects–my code was becoming impossible to read/understand using *setref and {var}, and trying to add one stinking new variable to the mix required me to go to a half dozen places and add in code just to manage the new variable. And it looked horrendous, with concatenations out the wazoo. With several characters running around, each with a dozen or more stats and each with multiple weapons which had about a dozen stats each, I just couldn’t take it anymore.
With the objects approach, if I now want to access the elements for, say, Joe, I use two commands to get at those values:
*get_all_elems char1
*get_all_elems_ref c_weapon_ref
With those two calls, I can now use the element variables c_name, c_sex, c_strength, c_heatlh, c_ammo, w_name, w_damage, and w_capacity. These “element variables” are normal CS variables, but they are currently loaded with the values pertaining to Joe (char1). If I wanted to get the values pertaining to Jane (char2), I’d do this:
*get_all_elems char2
*get_all_elems_ref c_weapon_ref
This would overwrite the values in the “element variables” (c_name, c_sex, etc.) with the values for Jane. If you wanted to retain some values for Joe so you could compare to the values for Jane, you’d need to save off the values of the element variables for Joe into some other CS variables before you got the values for Jane. This uses a bit more space, but you only need extra CS variables for the values you want to compare. There are additional object instructions that allow you to copy just the element values you want into other CS variables, to help with that.
Sorry for the long reply, but I hope I’ve addressed the question of space differences satisfactorily. 
From a practical viewpoint, however, you’re right.