This is a perfect answer to all of my worries, thank you very much for the detailed response!
I also never knew how many tris spheres used. 
Clarifying for your triangle overcrowding example, would this suggest that performance/crashes would mainly occur in dense geometry/triangle areas instead of having a “large” part count overall?
Additionally, for the competition section, where did those numbers come from? I’m curious - they seem right to me, and it’s a great ballpark.
That is indeed true. The distance I’m currently doing is about 5K with an atmosphere object. It seems to work well, hides the geometry, and shows no signs of floating point errors.
I may stand corrected, however if your game sits in the ballpark of 5-10K parts, it’s much better to preload the game once. Roblox can handle 5-10K parts with great ease.
Take a look at these numbers:
Jailbreak Part Count: 19,000 - 20,000
MadCity Part Count: 25,300 - 25,500
MeepCity Part Count (Mobile Champion): 13,500 - 14,000
All these games are playable on mobile and MeepCity itself is designed for mobile with a part count of 13,500 - 14,000.
What to take from this,
Meep City’s use of StreamingEnabled is justified because of the quantity of triangles they’re loading in and out. You really have to consider if your game is heavy enough to justify StreamingEnabled because loading in and out parts like that is very memory taxing. I personally feel you’ll be better off preloading your game as it is very light at the moment and skipping over streaming enabled completely.
With the variables you’ve given us, it’s clear that your coding will create a much higher impact on memory than parts or meshes will
I think that’s a good callout. My game isn’t as dense and won’t have nearly as many unique assets as MeepCity - so StreamingEnabled is likely overkill. Wireframe view shows very minimal tris.
My final question - is rendering reliant on the camera’s position and what it can see? Or is it a specific radius around the camera? From your triangle overcrowding example I’m guessing the former.
Using part count to judge performance is kind of inaccurate, as everyone has said. I recommend you export your whole game to an editor like Blender and view your triangle/vertex count there. Because those matter for your actual performance.
A part has 12 triangles and 4 vertices, so you don’t really need to do this if you aren’t using that many meshparts (you can just multiply this number with the amount of parts you have), but just to be sure.
From the top of my head I don’t know the amount of recommended triangles for a game environment, but there are definitely statistics out there. You just generally want to keep that number as low as possible.
I think there’s a case for both, certain scenarios where the former or the latter would be more intensive or more impactful. I usually test by a case by case basis when it comes to something like this, but I recommend you to wait or search for a definitive answer.
A big worry of mine is that this game will experience this feedback through trial by fire. Suddenly seeing the game’s likes/dislikes ratio tank or seeing “devices filtered” a few days in will not be ideal.
I plan on testing it with my small array of devices to ensure it performs as best I can - but once it goes out to Roblox there’ll be a lot of devices I couldn’t test for.
Irrelevant to the point of optimization, however I highly suggest you adopt the standardized shipping process that most ROBLOX games go through now.
Conception
Development
Soft Launch <
Official Release