As ever the best way to deal with performance questions is rapidly mock something up and take real measurements. This will help you identify what the real problems are rather than speculating.
I think with a large open-world style game the main issue you will come across is managing GPU memory efficiently. It would be all too easy to just load in hundreds of megabytes of textures for all the content and end up with really high system requirements. You'll need to make careful use of C3's memory management actions. Splitting content across layouts is a good idea if you can, since the C3 engine will then handle per-layout memory management for you (and it will also tend towards having fewer objects).
Other than that, make sure you enable "render cells" for efficient drawing on large layouts, especially on layers with mostly static instances. Then, providing most of the far-away content is static, the engine is highly scalable (i.e. more or less able to work in constant time regardless of how much more content there is in the layout). If you have far-away objects moving or having events tested on them, this will consume more CPU time, but then this is entirely within your control as a game design issue and not an engine issue.
One useful performance approach for open-world style games is to use overlap conditions to reduce the set of objects to run events on. Suppose you have 5000 instances spread across a huge layout. Normally a single event on that object will have a high CPU overhead, since it must test all 5000 instances. However you can take advantage of the efficiency of collision cells to reduce this. If you make a large invisible rectangular sprite as large as the area you want to count as "nearby", and then pin this on the player, the condition "is overlapping NearbySprite" is very efficient since it uses collision cells to reduce the instances to check against. In other words it won't check all 5000 instances - it will only check against nearby instances and then filter those down to the ones overlapping NearbySprite. Then you can add more conditions to the event, and the rest of the event runs efficiently only taking in to account nearby instances, without ever having to iterate everything in the layout. (If you're worried about the performance of collision checks, they're pretty fast, and in this case the main point is to improve the algorithmic efficiency, i.e. reducing the number of instances processed.)
You can then extend this to a single "X is overlapping NearbySprite" event and all the rest of your logic for X in subevents beneath that. Then you have an efficient way to only run events for objects that are nearby - the amount of CPU time won't increase no matter how many far-away instances are added.
I don't think anything else will prove to be as significant as those points. In particular using folders has zero impact on CPU usage, and the GPU rendering performance only relates to what's on-screen, so is naturally scalable regardless of the size of the layout.