To elaborate on what Wardy said, there are some really important object attributes that are integrally related to this tree structure and could not be expressed as easily if the objects were merely stored as a "scene list". For example, take position and scale. Normally moving an object will also move the children. This is because each object stores its scale as an offset from a parent. It's very convenient, and it would not be as straightforward if objects were stored in a different way. Scale is similar--if an object is marked as scale=50%, all its children will be also.
The king of attributes is whether an object is active--should it be updated? Should it be rendered? So if you set a character inactive, his skeleton, his guns, his hair, etc., will all become inactive. (This isn't true for all game engines.) But an intelligent game engine can assume that if an object (the character) is disabled, the child objects underneath have no need of continuing logic. The hair doesn't need to blow in the breeze. And because of this tree structure, you don't need to update the attributes of all the children. The way Unity expresses this is having two ways to look at object activity: "activeSelf", and "activeInHierarchy". The former is the "active" bit, and the latter is whether it's really active (based on its own state, and the state of its parent object).
(I meant to post this as a comment, but I accidentally typed too much because the text box didn't tell me to stop! Well, I was typing in the wrong text box. ;-) )