It appears the answer is "yes". BLE throttling can occur for a variety of reasons and throttling control is not accessible through the Android WearOS or Apple WatchOS APIs. Quoting this research paper:

"The data packet loss in the wearable healthcare ecosystem is complicated by the following factors. First, a larger packet size is preferred in the wearable healthcare ecosystem. Typical Bluetooth 4.0 only supports 23-byte data packet transmission. However, in the case of Body Sensor Networks (BSN), where multiple wearable devices are involved in the ecosystem, the combined data are streamed with larger packet sizes, up to 255 bytes [ 13, 14]. Second, the BLE chipsets and operating systems (OS) are very diverse in the wearable healthcare ecosystem, especially considering that off-the-shelf smartphones (Android, iPhone) or Raspberry Pi are often used as the hubs [8 , 15, 16 ]. Third, the optimized factors associated with packet transmission between peripheral wearable devices and central host vary among BLEs from different Original Equipment Manufacturers (OEM). These factors include connection parameters, signal strength, external signal interference, and data corruption [17 ]. For example, iOS has a set of defined values for connection parameters to the device developers and limits the maximum transmission unit (MTU) size [ 18]. Android, on the other hand, allows application developers to set the required MTU size. Finally, the interaction between the BLE chipset drivers and the custom application in a host could also cause data packet loss. Most modern operating systems use a Hardware Abstraction Layer (HAL) to abstract internal hardware drivers and parameters from the external application [ 19, 20 ]. The developer invokes a standard function to request a BLE-specific task and provides a callback handle, which is then invoked back by the OS when the internal drivers complete the requested action. The number of functions exposed by this interface is limited to the most critical operations. It is also possible for the packet to be delivered to the underlying hardware chipset but not passed from the chipset to the requesting application function due to other high-priority tasks running simultaneously on the host. Eventually, the chipset might start dropping packets due to scheduling and priority conflicts. These complex nuances make developing a robust BLE-based data transmission scheme between the wearable peripheral and the host very difficult."