The general pattern we've been encouraging is to put the "Sensor" resource in the physical container that holds the sensor, which means for a NIC or storage controller, the "Sensor" resource will be in the Chassis resource that contains the device. This gives the type of user trying to find all readings regardless of the context an easy location to find all sensor readings for a single container.
Keep in mind, there are also "EnvironmentMetrics" resources subordinate to device resources if the user wants to a single location to get readings related to a particular device instance. "EnvironmentMetrics" can reference back to Sensor resources to show where the reading information is stored.
Within the mockup, there is a single "Chassis" resource called "1U" with a SensorCollection that contains all of the Sensor resources. If you then go to /redfish/v1/Systems/437XR1138R2/Processors/CPU1/EnvironmentMetrics in the mockup, there are several readings shown there that are relevant to CPU1. The "DataSourceUri" property for these readings points back to members of the SensorCollection within the "1U" Chassis.
As Mike said, the "EnvironmentMetrics" resource is available under most subsystems, and that is intended to hold the "sensor data" specific to a controller, processor, etc. That resource uses excerpts of Sensor resources - but also note that you can populate simple readings in EnvironmentMetrics without a Sensor resource backing. For items like a StorageController that may simply want to report a temperature or power reading, without setting up thresholds, etc. that becomes a low-effort implementation.
But for actual Sensor resources, it was beneficial to clients to keep those in a central collection for each physical container. Otherwise, a client attempting to gather "all sensor data" would have to traverse the entire tree looking for dozens of collections (each with probably one or two Sensors).