Note that the GedcomX PlaceDescription type has no hierarchy like Gramps, and some of the web services that I know, but is just a list of names that can use different languages. The latter is nice, but may also become quite a mess, I think. FamilySearch probably chose this, because it is compatible with the normalized places that they already have, and can be extended with localized normalized names, but it is not very compatible with what we have now, because in their system, there are no types. You can recognize levels in a normalized string, but you don't really know what type these levels are.
The executive summary is that we decided that for interchange purposes it made more sense to flatten the structure into a comma-delimited string rather than to enforce a particular hierarchical model on client applications. Apps which use a hierarchical model are expected to serialize/deserialize the string from/into their model. No "place authority" is specified for helping to disambiguate the string, but clients are encouraged to use one, and FamilySearch provides one for its users. You'll see toward the end of the discussion that the Secret Force (whom I believe to be the FS FamilyTree dev team) directed that the two classes PlaceDescription and Place be flattened into a single class, but that's immaterial to the serialisation of the place hierarchy.