Needless to say, most formats handle resources such as geometries, textures etc separate from the nodes using them (but you should check if the one you use does that). So the big memory of resources should be only stored once in the file anyway, but if you use JSON those files will be giant as they’re stored in text with many float digits and textures even base64 encoded.
However, the children of what you’ll consider 1 component sure are dublicated as it doesn’t has a concept for what is a component. It depends where you do this, i do similar by default just linking used assets or effects like particle emitters in a custom asset format, binary and json only for varying data.
You could do this a simple way too, for example changing the export part in the editor so when exporting you replace all the models that are the same with a basic THREE.Object3D, and put the reference name in the userData object or name, only store the original model once in the screne, when importing you just replace those nodes with the model again without dublicating stuff.
However if you want it to be more efficient you should use a geometry with buffer attributes to store the big mass of default attributes like position, rotation etc, not that you use this geometry for rendering (unless you just straight use them for instancing as @prisoner849 suggested) otherwise just to store all that data as buffers, if all the objects are flat in the scene without hierarchy, you can even entirely skip all the objects in the scene, since if they’re present they will pile up tons of json text regardless if GLTF or GLB)
In my case for the game-level scene format i store everything binary with a lookup table of the assets used, and if a few have special properties that are easier stored as json a lookup to that one, otherwise just a plain buffer that contains all the straight data to quickly and with a small memory footprint store and restore millions of objects.