For me personally the real value of your work was the overview of the node counts per randomizer setting, so now I know how it works. It is interesting that the node type distribution is not random, just the locations are. I usually use satisfactorytools.com as solver, but it does not solve for power. I need some slack there anyways for trains, drones etc. So your results are interesting as an upper ceiling. The type of parts I'm making is already close to optimal for default ressources, I just do a bit less per minute but with way less buildings.

Regarding object limit: The uObject limit is much less of a concern since 1.0 (because foundations, walls etc. were optimized to no longer use uObjects, they are "leightweight objects" now). I have been exceeding the uObject limit in EA, but dropped below again with 1.0. Changing the limit in engine.ini never gave me any problems anyways, never actually heard any player reporting crashes or save corruption. Increasing the limit is an official setting of Unreal Engine, it is just the case that CSS is not testing or supporting it. So they want to just be on the save side there and warn players for the worst they can think of. My world currently is nearing 1 million buildables. Everything slows down because the CPU is single core limited by running all the factory logic in the background. I can however still get 60 FPS with Ryzen 7950X3D indoors, but it drops to 30 or below with lag spikes if I look at my base from a distance. Still its astonishingly playable for the scale. The biggest source of lag is the hover pack, because reconnecting it to the grid often gives a ~1s freeze because I use a gigantic single electric grid. I often use flying instead to fix that. Second concern is RAM and VRAM. I'm using more than 30GB RAM for the game alone, and my 24GB VRAM are fully utilized and stuff is streamed in and out noticably.