Well, question is whether a wheel as part of a car should be its own entity at all… But nevertheless, let's use it as an example. Of course, I describe it the way I'm doing things. Other solutions are possible as well, you know. A description in code snippets is meaningless until the API is known, but the API is engine specific; so I stick with a verbose description.
Create and entity for the car body. Create another entity for a wheel. Create a Placement component for the 1st and another for the 2nd entity. Because of the existence of the Placement components in their initial state (i.e. identity transform) both entities are located at the world's origin and are facing along, say, the z axis. Notice that both entities exist side by side and not hierarchically. I allow nesting entities in the editor not for the sake of dependency but just for a logical grouping, allowing the designer to straighten up things to its wish.
Because there is nothing set-up that alters the both Placements, both entities are static. Now create a Parenting component and assign it to the wheel entity. The Parenting component is assigned to the entity whose Placement component is to be controlled, i.e. the "child" entity. In order to complete this step you obviously need to tell which entity the "parent" role plays. So attach the car body's entity to the Parenting controller's parent slot.
Now we have a mechanism installed to the wheel that computes the value of the entity's Placement as usual for parenting, i.e. when using column vectors:
my_entity_Placement_value := parent_Placement_value * local_placement
Nothing has changed on screen because both right hand side transforms are still identity transforms. So translate the wheel to where it should be located relative to the car body's placement. In fact you do not alter the wheel's Placement directly but the wheel's Parenting local placement value.
When you compare this with a scene graph solution, then the parenting is not expressed by a wheel node below a transform node below a car node, but (when still using the term "node") a transform node below a wheel node besides a car node.
The sense of this set-up will become probably more clear when thinking of other mechanisms (I'm supporting 12 different mechanisms at the moment). Let us have a look at targeting. Let's say you have a Tracking component installed to a weapon, and it tracks the Placement of an enemy. For sure weapon and enemy are 2 real distinct entities, and putting the one as node of a scene graph into the other makes no sense. Instead, both live side by side in the CES and the one is explicitly expressed to target the other by the current existence of a Tracking component.
Besides the mechanisms mentioned above, there is another kind of controller that fits into this set-up: Animation. Let's say the animation sub-system currently runs a track that changes the local rotation of the wheel's Parenting component. Voila, the wheel rotates in place, and it moves with the car body.