Based on ID
The Identifier is the only way to recognize that the message is of from which CAN Node. Usually, these identifiers values were decided by the OEMs based on the priority of the message, bandwidth in the channel etc.
Say for example, the temperature sensor which senses the AC & Engine does pretty much the same. But it doesn't have the same level of priority assigned to it. Typically, Most of the nodes in the vehicle doesn't "need" the AC temperature for changing its behavior or being cautious about. But Engine temperature is important. More ECUs consume Engine temperature than the AC temperature. So, obviously it has to have higher precedence. This is achieved by assigning a high priority ID.
Lets take another example of Wheel Speed Sensors.
Unlike the temperature sensors you mentioned, All the wheel speed sensors are as important as the other. All the sensors were "identical" and does the same. However, the OEMs have to come up with ideas to "effectively" share the bus with the sensors. That is basically assigning IDs and designing the payload of the frame.
So, possible way to avoid clash in the sensor values in the bus is to have different IDs and framing the payload in the frame.
If the sensors were "identical", you can always replace the sensor from one node to the other. But, you cannot replace the complete Sensor CAN Nodes.
A Sensor CAN Node is not just a Sensor. It has more properties than
acting simply as a sensor.
To clear how OEMs handle the "identical" sensors. Consider the Temperature Sensors as example.
We have one temperature sensor attached to the Engine ECU to monitor the Engine temperature. We have another temperature sensor attached to the Body ECU to monitor the vehicle AC temperature. Even if the sensors were same, but those were attached to different ECUs. This is because of the fact that the vehicle AC can be turned ON even without the Engine being ON. So, we effectively need to monitor the AC temperature whenever the AC is ON. This means, the "identical" sensors need not to be used together or controlled together.
So, consider now in the dashboard, we are seeing both AC and Engine temperature. Take, the AC temperature is 21.5 degC and Engine temperature is 78.255 degC.
We need higher precision for the Engine temperature to activate the Engine Overheat Alarm or activating a coolant on proper time and to learn the rate of change of temperature over the time.
However, the AC temperature is used to maintain the same climate in the vehicle for Automatic Climate Control functionality. This is not as high priority and +/- 0.5 degC is far more comfortable.
So, to clearing things for you, The sensors were same. But, the precision were different based on the functionality it is used. You know how to change the precision, reference voltage, ADC, etc. This also reflects in the payload of the CAN messages which carries the sensor information.
You know, we cannot send the floating point value in the CAN message. we need to convert into a whole number by multiplying with a factor and the receiving ECU has to retrieve temperature by dividing with the same factor.
So, to send the temperature without any losses, the AC Temperature will have a factor of 10. which makes the value range from 0 - 512 (0 to 51.2 degC) which only needs 9 bits to transmit. However, the Engine temperature will have a factor of 1000. which makes the value range from 0 - 131072 (0 to 131.072 degC) which needs 17 bits to transmit.
So, to answer your question, OEMs chooses ID to priorities the sensor information and frame the payload to make effectively use the sensor values. Beside these there were a lot of other concerns in designing the CAN network for a vehicle. I'm just trying to keep it in context and not to confuse you so much.