There are technical reasons, though.
Let's suppose we have a pacemaker, and it has data that is beneficial to read -- maybe even in real-time on their pocket computer, or opportunistically as the patient walks by their reader-device, or however that is done.
So we want this data, and we want it over RF. It probably seems obvious that it should only transmit when it is told to do so, right?
So how do we tell the pacemaker to transmit? On its face, that problem seems solved by integrating a receiver that sits and waits for a valid instruction.
Except: That receiver takes power to run. And since changing batteries inside of a person is problematic, we want them to last as long as they can while still performing the desired task.
Now we get to the not-obvious part: In terms of power, it's often less costly to intermittently transmit a string of data than to continuously operate a radio receiver. And maybe it's a bad idea to have an implanted pacemaker that has an open receiver for anything nearby to try to fuck with, anyway.
But a transmit-only radio? Good luck hacking that.
So... we do intermittent transmission, and this works for pacemakers. It also works for the cheap Zigbee thermometer I have (wherein I don't normally request the temperature; it just delivers it periodically, and it runs for years and years on a coin cell).
(Now: Should that pacemaker data be encrypted? Yes, of course. And so should the ID. In fact, the whole transmission should be indistinguishable from background noise by unrelated devices. In this way, authorized devices can then use pre-shared keys to receive and decode these messages and others receive nothing. That kind of cuts BLE and thus also the pocket computer out of the monitoring mix, but tradeoffs are tradeoffs.)