Nesting is physical, part-of hierarchy. It is how you convey the idea that an object is an assembly, collection, or container of inner objects that can be manipulated (moved, scaled, etc.) as a single thing. It is not bad per-se, though an object that contains nothing but a single nested object serves no purpose and should be exploded. Also, excessive nesting can cause a model to be difficult to work with, as you have to drill down through the levels to get to the inner ones to edit them.
Some properties of a container objects dominate those of its contents. For example, making a group non-visible makes its contents non-visible. That’s one reason it is not necessary to attach the container’s tag to its contents too.
In a few cases a property of a nested object may dominate over the container’s. For instance, if a nested object is itself hidden, its container can not cause it to be visible. Also if a nested object has a material applied, that is shown instead of the container’s material.
The Outliner shows the nesting hierarchy and allows you various ways to select, open for edit, hide, etc. objects directly, which bypasses the need to open them recursively in the model view as noted above.
Tags attach a non-structural “what is this?” category to an object. A object can have only one tag applied. The primary use of tags is to turn on or off visibility of multiple related objects at the same time. Tag folders allow you to create a what-is-this hierarchy.
A group is a special case of a component, and they share most of their properties and behavior. Both have an underlying definition that specifies what geometry makes up the object and have concrete placements of that geometry in the model, called “instances”. Groups use a small amount less memory than components, but that shouldn’t be the basis for choosing between them, as the difference is usually a small fraction of the total. The main difference is that groups are meant to be singular, unique objects whereas components are meant to have multiple copies that share most of their properties. Also, components are able to be saved out to a separate file for reuse in other models.
A potentially confusing aspect is that a group may also have multiple copies. The difference is that editing a copy of a group automatically separates it from the others, whereas editing any instance of a component immediately makes the same change in all the other copies. So, copies of a group should be reserved for static, unchanging things.
Another difference is that naming is handled differently for groups and components. In both cases, the definition has a name. But for groups the name is internally generated by SketchUp and can’t be set by the user. For components, the user can supply a definition name, though SketchUp will automatically assign one if you don’t. Also in both cases, each instance can have a distinct name set by the user. The instance names let you keep track of which instance is which in the model.
If a group instance has a name, the outliner will display it. Otherwise, it just shows “Group”. So, if you don’t name instances, it isn’t possible to tell which group is which in the outliner. If a component instance has no name, the outliner will display the definition name. The auto-generated ones are like “Component#27”, which isn’t of much use. But if the instance has a name, outliner will display both the definition name and the instance name.
