Apparently that's the intended behavior; see LR 5.4: GPS data not reverse geocoding if Sublocation manually defined - Lightroom Forums
The rationale is that if you change one you may not want the rest. But you have to confirm EACH field; no way to confirm all. Giant PITA since it happens even if you are writing into a blank field where nothing changes. The truly odd thing is that in my bigger catalog it doesn't always happen; sometimes the suggested fields (which on my machine aren't italicized but are greyed out) remain. Even when I go back and forth between photos, and then they reappear, or not. This means that if you lost "city" in your example you couldn't even find that photo in a search, whereas the photos you didn't change the sublocation on WOULD be found. Dumb.
But do yourself a favor and get Jeffrey Fried'ls Geoencoding Support" plugin at Jeffrey Friedl's Blog » Jeffrey’s “Geoencoding Support” Plugin for Lightroom
Screenshot below of his Google lookup dialog for an individual photo, with your location at the Mission. Note that unlike LR by default ALL the suggestions are checked "apply." I had selected a different priority for the "location" field, hence the intersection prevailed over neighborhood. It's a choice, and you can change it.
You can avoid the problem in the first place if you use the plugin to reverse geoencode; note that his plugin provides the raw data from Google, and Google doesn't provide the mission's name for some reason. Must be new.... But you can see that "Mission Point" came from "neighborhood." In the plugin you have the option to change that priority. You could also do your own custom locations via KML files. But I usually just manually change it in the plugin. As another example, Google gave me "Redwood National and State Parks"; I changed it to a more specific sublocation of "Prairie Creek State Park." I find that out in the boonies where I do a lot of shooting even the city name isn't useful. And it has a bunch of other goodies. It would still be nice if there was a way around the problem; we should suggest it over at photoshop.com.
Thanks for the comprehensive and interesting reply, its lots of learning with the geo-tagging, as it seems. Regardless all this, I fail to see any rationale in abandoning GPS provided tags only because one introduces a detailed or a different "sublocation". This is absurd. Personally, being a veteran in software business, I have a good impression about what might have been running behind the scene. I suspect that the development team run out of time, someone was yelling and threatening them, and they declared faults and misses in the user interface as "intended behavior." And so it stayed, to dismay of the users. And once documented as "intended behavior", not merely technical aspects play a role, but also purely workplace related factors dictate the internal decisions. These might include losing face, admitting to a mistake, office politics and job preservation instinct.
You're probably right...since the "intended" effect is absurd, and rather contrary to what happens with other software. But just one reason why I don't use LR for geotagging (I use HoudahGeo a lot). Another issue is that LR only has a very limited map selection (Google). The particularly annoying part of this is that it's a pain to work around.