The exact quote is "Premature optimization is the root of all evil" (attributed to Donald Knuth). And in this case - when the author plans 50k x 50k map - I don't think the optimisation is premature.
Personally, I'd be wary of handling such a massive map all at once - 50k x 50k means 2500m, so if each cell information took only one byte, the whole map would take whooping 2.5GB of memory. The memory is cheaper now than it has been in earlier days, and usually computational processing time it more of a concern, but in this specific case you might want to slow down with loading such a massive thing all at once.
Maybe try splitting the game region into smaller maps (I dunno, 500x500 is already pretty sizeable, with 250k cells) and generate more areas as you play? You might still need to save each area the player visits, but this kind of incremental approach should be easier on both the runtime memory and disk storage. You might also cap the world size by generating "rooms" layout upfront - along with which room should connect to another - and generate newly visited room so that they respect the connection rules. That way you can ensure the world never gets larger than, say, 100m cells, which should make save files potentially lighter as a result. If certain parts of layout are randomly generated but never change aftereards (e.g. land + water + mountains or something) you might also save a random seed used to generate them which would be dirt-cheap to store, but you'd also need to have an RNG of your own so that it works consistently across platforms. Still, large sequences of same kind of terrain should be easily represented by something like "W123L45W34M12W12", with numbers corresponding to how many units of specific terrain should be added. So if you want to store the maps without taking too much drive space, there are various options.
As for the game itself, personally I'd opt for creating a grid (or several grids) with width and height the same as the map size. Then, based on data of these grids and on current camera positions, I'd determine how many cells are "in view" and draw only them.
If there are more interactible or animated entities, I could also setup corresponding objects and either activate/deactivate them (as your original idea) or create/destroy them depending on whether they are roughly on screen or not. Or, if these objects are scarce enough, I would keep them activated (so that they can still participate in interactions and proceed with their animations or whatever) but instead prevent drawing them when they are off-screen. Limited time animations/effects like tree falling down or grain being harvested should be so relatively rare and short-lived that you won't need to bother activating/deactivating them; just let them play out and destroy them afterwards.
So yeah, the general takeaway is:
- 50k x 50k is a lot, you don't want that kind of map loaded all into your memory, and might instead want to split it into other areas
- 500 x 500 is more manageable, but you still want to limit the amount of cells and objects being drawn
- the general terrain (waters, lands, mountains etc.) should probably be handled by a ds_grid rather than individual objects, since an object can add quite a large memory overhead
- objects that are relatively frequent compared to the number of cells but are simple counterparts of cells might need to be created/destroyed depending on whether they're on screen or not (something like high grass that adds an animation and sound effect when walked through)
- if certain objects are somewhat rarer compared to the number of cells might be deactivated when off-screen, or even just keep going as usual but don't draw when off-screen (maybe something like monsters? I dunno)
- short-lived objects can just be kept active and drawn, since they're likely infrequent enough not to be a problem
The rule about "premature optimization being the root of all evil" still stands. It's best if you play around with whatever sized maps you'll create and see whether the performance stays at acceptable levels or drops too much, and then try to employ some optimisation strategies.