The number of items is what bogs down the game, not the size of the lot.
First issue we have is draw calls. For each “object” on the screen your CPU needs to make a draw call in order for your graphics card to render it. The more items are on the screen at once, the more draw calls are needed at once and thus more work for the CPU. Because TS4 uses the very outdated DX9 as the graphics API, draw calls have huge CPU overhead and can only be pushed on one CPU thread. This means it doesn’t matter if you have a 4 core, 8 core, or 16 core CPU, only one core can work on draw calls. Once there are enough items on the screen, everyone’s game will slow down (in the form of lower FPS), as processors with extremely fast single core speed (10GHz for instance) simply don’t exist.
Second issue is the simulation. The more functional objects (this includes objects that merely have slots, such as shelves) the longer it takes for the game to process simulation. TS4 not only has the standard full autonomy requests, but the multitasking system also constantly searches on the posture graph. The size of graph is proportional to the number of functional objects you have. More items = larger graph = longer search times = slower game (in the form of simulation lag, as opposed to lower FPS). And if you’re not aware, TS4’s simulation also only runs on one single CPU thread.
In short, can the game a handle a 90x90 park with a reasonable number of objects, a majority of which being purely decorative? Most likely yes. Can the game handle a 90x90 apartment complex with dozens of fully functional units? Absolutely not.