Why do Transform have hierarchies and not GameObjects?

The GameObject act mostly as a container for components (such as the transform, or a renderer). It is the components that give shape to the game behaviour, not the game objects themselves really. While Unity requires each game object to have a transform component for some reasons, imagine a game that used this architecture might not require it. It would be a strange design decision to have the game object know about parents and children if they aren't needed (I can imagine having a component based design for a text mud game where parenting stuff might not be that useful). Parenting belongs to the transform (the position etc of objects) since it uses this information to calculate the position from local coordinate systems. Think of it, it becomes almost about useless to parent things unless you consider their position.

A game object is about as void as it can get. It is just a container for components. It is the components that are attached to it that make them "physical". The transform describe where an object is. A renderer makes use of a mesh filter to render the mesh at the position derived from the transform. A collider component describes its collision properties and a rigidbody makes use of the collider and transform to generate physical movement. All of the components then work in harmony, doing their job and their job alone.

A lil off topic:

If you were to create your own very basic component model game from scratch you'd probably get to the same conclusions. I have toyed about trying to "improve" (Well, in ways I thought unity lacked) this architecture but I came to realize that things are the way they are for a good reason. For one, even such a silly thing that having public member variables camelCased instead of PascalCased proved to be a good approach since it resolves the ambiguity of accessing member variables vs accessing class variables. You also get to appreciate that the transform deal with the parenting code and not have it hard coded into the game object. But I agree it could just as well be included in the interface of the game object since you can't create a game object without a transform in the approach Unity favor. Unity was meant to be a 3d game engine so it's a quite central piece to have. But boy, would I want to trade it for a transform2d sometimes when making 2d games... :)

A transform is a scale/rotate/translate operation. When one object is attached to another, it is "transformed" by its parent -- its own (local) scale/rotate/translate is combined with that of its parent. The chain of operations that transforms a specific object is actually the chain of transforms of its ancestors.