OK, you win, you convinced me to finally read that discussion from cover to cover. What I learned from approximately half of it is that a pull request on GitHub is not the right place to have a tagging discussion, so I guess we’re doing something right for once over here. 
Personally, I see the old place areas versus nodes debate as a false dichotomy driven by a thirst for consistency and elegance. For better or worse, place=* is a hodgepodge of values. Nothing about place=farm or place=square should inform how we ought to model place=city or place=state (or place=continent for crying out loud). Therefore, it shouldn’t be surprising that some kinds of place=* are better represented as areas and some as points. And some not at all, because they’re actually better described as administrative boundaries.
We can’t necessarily expect mappers to agree on a polygon representation of a large settlement as it would be known in settlement geography. Earlier I linked to a U.S. Census Bureau informational video from the demographic experts who so confidently delineate urban areas that they wrote the process into law. I wanted you all to see that even they recognize that the shape of a settlement often matters less than its center of gravity. Nevertheless, there is a place for crowdsourcing subjective geographies, as in Quattroshapes, Foursquare’s “authoritative” dataset of named neighborhood polygons based on Flickr’s user-contributed geotags.
Despite what I’ve said in this thread, you won’t find a more ardent supporter of two-dimensional places than me. I just haven’t been modeling them as closed place=* ways since approximately 2008. One of my favorite things to map is named landuse areas, which very effectively capture the structure of place in the midst of American suburban sprawl. Moreover, everybody’s favorite capital city of late, Washington, is currently a boundary=place relation at my suggestion.[1] It fills the space within the District of Columbia by process of elimination. But I still wouldn’t eliminate its label node, because the shape of D.C. is not the only reasonable answer as to the shape of Washington.[2]
The GitHub discussion focused very narrowly on two rationales for a place=city node: getting driving directions to a city by name and labeling the city as a point feature. While these are valid use cases, they are merely symptoms of a trait shared by a great many cities. Each city has its own local convention for breaking up the urban monotony into an interior hierarchy, with a particular spot at the pinnacle of that hierarchy – a focal point, if you will. Under a typical North American grid plan, this point is often explicitly recorded as the origin of the street grid. Other cities may require knowledge of local history or customs (or deference to an authoritative gazetteer). A city’s focal point could overlap with its navigable point in some cases, but there’s more to it than navigation.
The duplicate labels at issue in that pull request have suddenly become relevant again with the new vector tile effort. Fortunately, it’s a solvable problem, even with the boundary and place tagging schemes as they’re currently documented. We just need to sift through the capitals, capitols, and focal points that have been conflated as admin_centre due to limited tooling and confusing documentation. Introducing less confusing-sounding roles could be worth exploring, but we’ll need to review that mistagging anyways.
The terms “capital”, “seat”, and “administrative center” are known throughout the English-speaking world, but each region chooses different words in different contexts. Even though all three terms risk confusion with administrative headquarters, maybe we could get away with capital simply because it’s already been around for so long as a key. I wouldn’t favor tying capitols to boundaries anyhow, because that’s too tangential to the boundary. It would be like adding a town’s public library or railway station to the town boundary relation, the kind of thing that happens with site relations.