EDIT: Ninjad by 
dop2000, lol. I echoed similar things, but yeah.
for example, if he using the global object as invisible while the Construct says is invisible cause is a html5 interpreter u are correct... but u have to take in consideration all objects in screen are rendered by canvas... even if the system is saying is "invisible" once in screen they are actually transparent
This is incorrect. An object marked as invisible is simply not rendered. You can test this with a blank project, have 3000 onscreen objects (and 1 other object moving so that the game ticks and provided measurements in the debugger), make them visible and invisible, and see the gpu improvement when they're invisible.
now in ur suggestion if is 1 object shouldnt do a big impact... however stacking that invisible object with 100000 variables that will take over globals to save "events" is a trade off i wouldn't even consider.
Its worth considering, but it's nice we have the choice on which path to take. An object's instance variable list, for all intents and purposes, is a dictionary - you can have 1000s of inst vars and would barely notice cpu difference, even if reading/writing to them often.
from mistakes like "forgetting what that invisible sprite does" to lets say u have a project team member coming in sees a object that has "seemingly no purpose" and deletes it, then all the game engine brakes.
This should never happen, because a team of C3 devs would know to right-click and use "find all references" on object they are unsure about. If they find references on the mysterious hidden object, they'll quickly realise what it's for in all the events they are listed. If they use "find all references" for the specific instance variable, again, helps here. Lastly, when you delete an object that has any events, it will warn you about deleting and ask if you'd like to "find all references", which the dev should be checking before deleting.
thats why i suggest better use json, arrays, dictionary anything that its purpose is to keep number values, text values by default.
I do agree with this! Dictionary is like an enhanced "instance variable" list, with extra benefits like getting the variable by name (which inst vars cannot do) deleting and adding new ones at runtime (again, inst vars cannot do) and link them to many different objects at once if ever needed, rather than adding inst vars repeatedly to multiple objects, or using family instance vars (which, both are great, but a dictionary being able to just link up to any object type, or even a family, is excellent).
The one benefit to a hidden sprite, is behaviours, like tween or line of sight. But you still could use a hidden sprite for those, but store vars in the dictionary.
i find myself more then 50% of the time, implementing ideas, patching things, then not commenting and going back to comment and i forget what everything does, and just stare at it and im like "it works, it made sense at the time, but what does it all mean" xD
Lolol yes, many times this happens. Or better yet, you think "wow wtf why did I design it this way, it could be way better!".
but considering C3/C2 is mainly used for tablets and phones, i know from past experiences sprite objects, and many instance variables on them, will glitch, like the variables will fail to be read and written.
This, I have never heard of, nor encountered. It should be reported as a bug if you can reproduce it. Does this bug happen with like 1000 inst vars, and does it happen with a dictionary with 1000 keys?
especially a sprite is easy to delete by mistake, or change its designated state by simply adding it in a familly by mistake, and then "woops" the familly gets destroyed when shot, and now ur invisible sprite that holds all user data gets removed or cleared.
I disagree - you could add a dictionary or JSON or array into a family by mistake, too! But if someone does this, then that's user error. Even ignoring the topic of a hidden sprite, if it's just regular game and someone decided to add an FX into a family that doesn't belong there, then they would indeed get unexpected results and must fix this or remove them from the family.
now memory wise you are correct once outside the screen no memory is used, C3 engine doesnt render nothing that is outside the screen.
Correct, and it doesn't render when onscreen but invisible. (it renders if visible but opacity is set to 0, iirc).
but is easy to remove a sprite by mistake once outside the screen.
But why? What if a preloaded particle was offscreen and invisible, why is it easy to delete it? Devs need to be more alert when they're tampering with the unknowns in a project!