Connect architecture
I would guess that the platform architecture was designed to preserve power whilst running over low bandwidth comm links. Data has to be compressed and packaged very efficiently when making use of very low bandwidth (or high cost) data links. That takes processing power which drains battery life. When the receiver has a finite sized battery and is expected to run for long periods, this can be problematic. It remains a key challenge when working with remote sensors communicating over satellite links for example.
In days of old, when connectors were male/female and masters controlled slaves, Bluetooth had higher power requirements and batteries were lower capacity. Add to that a watch sized device meant to run for days. Power savings could be made if the full data stream did not need unpacking and converting continously by client apps.
Then consider the lower software costs of maintaining a single reporting API that doesn't need rewriting with each new form factor or device and it kind of makes sense.
Finally, replace the engineers with the beancounters and why change a working product not milked completely dry yet?
To be fair I personally found the Garmin Connect APIs to be well designed and implemented,and the support first rate. Unfortunately the licensing terms meant only those with a serious enterprise budget could access the data in near real-time. The rest of us had to make do with whenever the user finally synced their device.
Biting the hand that feeds IT
