There can be many 'why'-answers for such a context. While we can see 'a sensor' with some properties like data format, refresh rate etc. that sensor is a mere 'implementation' of a desired functionality of a product design.
It used to be that the designed feature or function would be very close to the implementation, but that really hasn't been the case for a very long time. People aren't buying "a large bank of memory addresses" but rather "a device that contains pictures", for lack of a better example.
With the watch a customer isn't actually buying a package of sensors, ARM-cores, BMS, Lithium-Ion battery, and display, but they are buying the experience of having a device that tells the time, notifies them if something happens and can track some aspects of their life so they have an overview of it later (be it for turning their life into a game or simply tracking their energy use/consumption). And then all of that for at least an entire day.
Why would the implementation of the feature result in a sensor that can be polled at a high frequency but is actually only pushed at a lower frequency? It's anyone's guess but here is my guess:
The sensor has its own specs but those are set in isolation and might differ based on implementation inside a casing, so they only way to get true data would be to have some form of calibration or offset where a low-power CPU core for sensor tasks just gets the raw values and applies the offset/calibration. Next, there is power consumption where they might have found the perfect balanced duty-cycle between data that has had enough time to cool down and be useful as well as power requirements for the sensor core and the sensor itself. So they have some sort of RT OS doing reading, processing etc. on a low-power core at a lower interval to get a 1% battery life increase. Do that for 10 sensors and suddenly it's worth it. It's quite an investment to have a team of people dive into the hardware, firmware and application development to do all that, so it's likely not a matter of "how can we spend a multi-million R&D chunk on making the hardware less useful", but rather some "how do we make millions of mass produced devices use a little bit less power" concept.
This is also where the push vs. pull comes from, instead of having every application do some interrupt or scheduling, you just ask to be part of a list of observers and when the data changes you get notified. Much more efficient, and if everyone has to do that, there is a much smaller chance of the user experience suddenly changing and support personnel (phone, in-store) getting complaints about something they can't fix because some third party app did it.
It used to be that the designed feature or function would be very close to the implementation, but that really hasn't been the case for a very long time. People aren't buying "a large bank of memory addresses" but rather "a device that contains pictures", for lack of a better example.
With the watch a customer isn't actually buying a package of sensors, ARM-cores, BMS, Lithium-Ion battery, and display, but they are buying the experience of having a device that tells the time, notifies them if something happens and can track some aspects of their life so they have an overview of it later (be it for turning their life into a game or simply tracking their energy use/consumption). And then all of that for at least an entire day.
Why would the implementation of the feature result in a sensor that can be polled at a high frequency but is actually only pushed at a lower frequency? It's anyone's guess but here is my guess:
The sensor has its own specs but those are set in isolation and might differ based on implementation inside a casing, so they only way to get true data would be to have some form of calibration or offset where a low-power CPU core for sensor tasks just gets the raw values and applies the offset/calibration. Next, there is power consumption where they might have found the perfect balanced duty-cycle between data that has had enough time to cool down and be useful as well as power requirements for the sensor core and the sensor itself. So they have some sort of RT OS doing reading, processing etc. on a low-power core at a lower interval to get a 1% battery life increase. Do that for 10 sensors and suddenly it's worth it. It's quite an investment to have a team of people dive into the hardware, firmware and application development to do all that, so it's likely not a matter of "how can we spend a multi-million R&D chunk on making the hardware less useful", but rather some "how do we make millions of mass produced devices use a little bit less power" concept.
This is also where the push vs. pull comes from, instead of having every application do some interrupt or scheduling, you just ask to be part of a list of observers and when the data changes you get notified. Much more efficient, and if everyone has to do that, there is a much smaller chance of the user experience suddenly changing and support personnel (phone, in-store) getting complaints about something they can't fix because some third party app did it.