Juliean said:
The one downside of this is that it couples the entity with the position
Yes, of course! Hence, why you may or may not want to make that simplification.
The draw-back with having entities with different kinds of transforms (or maybe MULTIPLE transforms – I'm a “forest” and I have 100 tree positions!") is that everything that talks about entities now needs to be aware.
For example, what happens if I add a PhysicsComponent to an entity that only has a GuiTransform? Now, you end up with cross-component dependencies, which can totally be solved mechanically using runtime asserts and such, but THEN you end up with an ordering problem. Not to mention, I prefer it when my compiler tells me I'm wrong :-)
Yet another option is to bake the component into the entity class using multiple inheritance. Each inherited component would be called with the main entity as an argument, and the components would use compile-time type checking to make sure the entity has the right dependent components. The draw-back there is that the storage for components now lives in the entity object, not in a nice flat array managed by the component system, plus all the lifetime shenanigans that come with that.
The main trick is to understand what parts are most important to your engine (iteration speed, number of entities supported, flexibility, runtime performance, …) and optimize for those parts in the engine. And, no, most indie engines do not want to optimize for runtime performance as the top priority – there are much more important barriers to finishing and delivering a fun and working game for an indie developer!