Aside from my comment (don't have the flexibility to pull back a specific post at the moment) the answer to your question:

#No, but...

There is no CPU gain or loss by changing scale. It's not even correlated, except for one case.

And that one case is rendering. When you scale an object (especially non-uniformly) then it cannot be batched with other like-objects. There are two kinds of batching, static and dynamic.

Static batching is super ridiculously fast. But....it only works on objects that don't move, rotate, scale, animate, or in any way change. They are static. This is functionally equivalent to Mesh.CombineChildren though it happens automatically and will have better results.

Dynamic batching is slower, but still faster than not-batching in most cases. Dynamic batching will group objects that have the same material together into a larger mesh, provided that:

• They have the same material (material instances, even if 100% identical, break batching)
• The total vertex-attributes is 900 or fewer (if more than 900, they will be grouped in batches of 900).
  • This value may change in the future
• The objects have the same lightmap
• Single-pass shaders (multiple passes will break batching)
• Real time shadows break batching
• The objects have the same scale
  • Non-uniformly scaled objects can batch, but the exact details aren't listed.

There may be an impact from having a view frustum that is very large (measured in AU) due to the large size/very distant object jackmont mentions. This is less of a concern than his comment makes it out to be except for the amount of geometry involved.

Largely speaking Unity can render a single 100,000 vert mesh faster than it can render ten 10,000 vert meshes (I cannot find the thread where this was posted now) but that test was done with a very simple flat plane. In terms of real impact, simpler geometry renders better at longer distance (also known as LOD = Level of Detail) because it's so small, calculating the UV and lighting details for something that's only a few hundred pixels shouldn't involve more than a few dozen verts: there's simply not enough screen space involved to make the increased detail matter.

Same thing applies to textures and animations: at very long distances where the object shrinks below the size of a dime, you can start using smaller textures and simpler models and disabling animation entirely: the user simply isn't going to notice.

However, all of the constraints involved in rendering these are GPU and RAM/vRAM based, not CPU.

Aside from my comment (don't have the flexibility to pull back a specific post at the moment) the answer to your question:

No, but...

There is no CPU gain or loss by changing scale. It's not even correlated, except for one case.

And that one case is rendering. When you scale an object (especially non-uniformly) then it cannot be batched with other like-objects. There are two kinds of batching, static and dynamic.

Static batching is super ridiculously fast. But....it only works on objects that don't move, rotate, scale, animate, or in any way change. They are static. This is functionally equivalent to Mesh.CombineChildren though it happens automatically and will have better results.

Dynamic batching is slower, but still faster than not-batching in most cases. Dynamic batching will group objects that have the same material together into a larger mesh, provided that:

• They have the same material (material instances, even if 100% identical, break batching)
• The total vertex-attributes is 900 or fewer (if more than 900, they will be grouped in batches of 900).
  • This value may change in the future
• The objects have the same lightmap
• Single-pass shaders (multiple passes will break batching)
• Real time shadows break batching
• The objects have the same scale
  • Non-uniformly scaled objects can batch, but the exact details aren't listed.

There may be an impact from having a view frustum that is very large (measured in AU) due to the large size/very distant object jackmont mentions. This is less of a concern than his comment makes it out to be except for the amount of geometry involved.

Largely speaking Unity can render a single 100,000 vert mesh faster than it can render ten 10,000 vert meshes (I cannot find the thread where this was posted now) but that test was done with a very simple flat plane. In terms of real impact, simpler geometry renders better at longer distance (also known as LOD = Level of Detail) because it's so small, calculating the UV and lighting details for something that's only a few hundred pixels shouldn't involve more than a few dozen verts: there's simply not enough screen space involved to make the increased detail matter.

Same thing applies to textures and animations: at very long distances where the object shrinks below the size of a dime, you can start using smaller textures and simpler models and disabling animation entirely: the user simply isn't going to notice.

However, all of the constraints involved in rendering these are GPU and RAM/vRAM based, not CPU.