You are partly correct, and my off-the-cuff example wasn’t 100% complete. You can still have more than one measurement-temperature in a room. For example, in my office I have both the measurement of the room temperature and the measurement of the internal temperature of my home server. These are measurements captured by different devices and even have completely different fundamental meanings: occupant comfort vs machine operational health.
Even if my initial example left out some details, the general idea remains the same:
At some point, in any even moderately-sized house setup you are very likely going to run into a situation where in one location you have multiple points that have the same semantic definition and you need to distinguish them based on the physical or logical distinction between these points.
You are not missing something, but you are also not taking advantage of everything the model has to offer (and nothing says you have to, there is no one-size-fits-all solution to the model). But, for example, imagine a room with overhead lighting (functional) and led accent lighting (decorative). The On/Off points for both of those would still be control-light from a semantic standpoint, but you might not want to turn off the decorative lighting when you turn off all the functional lighting. The equipment layer of the model provides you with the ability to make that logical distinction by modeling your overhead light as a Lightbulb or WallSwitch and your accent lighting as a LightStripe. To take your example of iterating over tags in a rule, it is much easier to iterate over the equipment in a location and just send the OFF command to any Lightbulb equipment group (which will then propagate down to the points contained therein) than to iterate over all the control-light points and then do further tests to decide whether or not to turn that device off.
The converse is also true: the equipment layer gives you the ability to collate different physical devices into a logically relevant system. Many of my home sensors have both motion and temperature sensing, but in my back yard I have two different devices one for temperature and one for motion. In the model, I can define both of those points in one semantic equipment and now the information coming from the backyard is equivalent in format and definition (e.g., for use in a standardized widget) to the information from all my indoor rooms.