A list normally has an index associated to every item in the list, like so:

• 0: item1
• 1: item2
• 2: item3

There's nothing wrong with that, until you start to think about what happens when many simultaneous users start to access the same data. As long as we do reads, we don't have a problem. But what happens if we attempt something else, such as deletion?

Normally when you delete things, the index gets reassigned. If we delete the preceding item2, we have a new situation that looks like this:

• 0: item1
• 1: item3

Imagine we do deletions based on the index and your data looks like this:

• 0: item1
• 1: item2
• 2: item3
• 3: item4

Now, two different users can access this data and one wants to delete index 1 and the other wants to delete index 3. We would probably employ a locking algorithm, so one user deletes index 1 a few milliseconds before user two deletes index 3. The intention of the first user was to delete item2 and the intention of the second user was to delete item4. The first user succeeds in what they set out to do, but the second one deletes an index that is out of bounds. 

This means that deleting things on the index is just crazy in a multiuser database, but in the case of Firebase, it means that lists are not lists when they are stored; they are objects, looking like this:

{
  212sdsd: 'item 1',
  565hghh: 'item 2'
  // etc
}

This circumvents the deletion problem and is, therefore, the reason that lists are represented the way they are.