I'm trying to understand the reasoning behind Unity3D engine design and this is something I can't get my head around yet: why is transform data stored in a separate component, instead of being a part of GameObject, like name, layer masks and tags? It cannot be removed like all of the other components anyway, there are no alternatives and thus no need for it to be removed.
Only the Unity developers can give their true motivation for this design, but one argument in support of doing it this way is that there is an argument that each class in a software project should handle one and only one responsibility. The GameObject is a named collection of Components, and adding position/rotation/etc to that means it would have 2 responsibilities. The Transform component handles position and rotation and therefore shouldn't also be responsible for naming or aggregating other (potentially unrelated) components. So it makes sense for these 2 concepts to exist in 2 separate objects.
More generally, this question asks "if there is a 1 to 1 relationship between X and Y, why is Y not part of X or vice versa?" And the general answer is that software is easier to develop and maintain when broken up into smaller self-contained parts, even if 2 parts always work together in conjunction.
Transform is a mandatory component in Unity.
The reason why a transform is a mandatory component is that game objects are located in a scene and therefor needs spatial information (position, orientation and scale) about that object. (This information is not always used, but keeping the transform component mandatory keeps things a bit more simple).
TransformComponent is the most difficult
Component to properly design in video game architecture. Almost every other
Component needs to know about a given
GameObject's position, rotation, or scale, so properly decoupling all of these interrelated systems is inherently difficult.
There will always be tradeoffs in architecture. By having
TransformComponent be static (i.e. not dynamic), developers at Unity can write code under this assumption. I would assume this makes things much easier on their side without adding much of an inconvenience on our side. This is akin to an object-oriented paradigm, where