Well, okay, let me give you some of my assumptions here.
I'm figuring that for the super-simple "dumb smart home" setups, there'll probably be just one or a few basic temperature sensors all relevant to the area, and the new system is fine for those.
And then there are the complex setups, like mine, which have multiple sensors some of which need to be averaged in, and some of which don't, and some of which aren't related to the room at all (CPU temps on servers, NAS hard drive temperatures, 3D printer nozzles, etc., etc.). I have a whole bunch of wiring using Magic Areas to filter and build room averages, and then Node-RED to factor the results together into tweaked values I can call "whole-house thermostatic averages", and that feeds the thermostat integrations, and so forth. Now, for myself, this is all shiny. I know exactly which values are right for which usages, so I can just drill down through the devices and entities and pick the exact right one I want.
But the ideas the blog post puts forward, that people who aren't me and don't know or care about how all that complexity-wiring works should just be able to pick "Area: Bedroom"/"Temperature changed" and have Home Assistant do the right thing are pretty compelling to me - because there are other people living here without my HA-instance knowledge for whom that would be a boon.
Now you're right: HA doesn't know which sensors are valid or which aren't. But in the above scenario, we've at least one person who built the system and does know all of that, and so can tell it where to get the data from. In fact, this is already done for some things. Here's a look at an existing part of the configuration popup for an area:
So there is a place where you can tell an area which sensors accurately represent the area values, for those two classes! It's just not used for this; I think they only apply to voice assistant questions.
So that's my ask. Give us the ability to, for each area and per device class, specify a particular sensor (or sensors) that accurately represent the area state. If it's not overridden, use the existing method: it'll work fine on small and simple systems. But adding this rescues the feature for complex-system use by people, non-admin users, who aren't fully intimate with their details, and that's worth doing.
ETA: Actually, as the admin user, it's also kind of convenient for me to be able to say "use the canonical temperature of this area" in automations, because then if I change the underlying wiring that computes it, I only have to change one setting in the area config rather than however many automations use it. But that's just gravy.