Bluetooth LE is a packet based system, that exchanges data in packets of limited size at a limited maximum frequency. The BLE MIDI specifications demand that sender and receiver should negotiate a 'minimum connection interval' that is not larger than 15ms, while the absolute minimum interval between two packets is defined as 7.5ms. Maximum packet size is usually ~520 bytes. In practise BLE MIDI devices mostly negotiate a packet-size no larger than 185 bytes. 180+ bytes of course is plenty big enough for the usual 3 byte MIDI message. However: Using an extra packet for every single MIDI message means that even a moderately complex chord consisting of three notes will take 3 * 15 milliseconds to make it over the air. And as the 15ms recommendation is just that, higher 'minimum connection intervals' will occur. Plus actual transmission on radio networks is under influence of various other things and will not necessarily operate as how some specification imagines it.

So even from a theoretical point of view and assuming that everything would work as good as it possibly can, BLE is at the very edge of being usable for musical input. In the end it's kind of an equivalent to portable Bluetooth speakers: In the interest of convenience you are supposed to accept that new technology actually is a significant step backwards: Even on standard 1980's DIN MIDI connections it will not take more than 1 millisecond to transmit a single Note message.

Now there are some ways to optimize things a bit and Apple's original specification already described them: The operating system's implementation should take care of actively bundling as many MIDI messages as possible into a single BLE packet using running status whenever possible. Ideally that would mean that whatever happens in the 15 milliseconds between two connection intervals is written into some temporary buffer before being sent off. MIDI messages inside a BLE packet can carry individual timestamps so the temporal relation between them can be preserved and could be recreated by the receiver.

Apparently the only operating systems that indeed do so are Apple's (I have not looked at iOS, but would assume that it will roughly be the same as on macOS). CoreMIDI aggressively aggregates what a DAW has to send and transmitted BLE packets will often be up to 182 bytes in size and contain MIDI that covers timespans that according to the timestamps within them are up to 100ms long. This of course only obscures the transport inherent 15ms latency and puts a lot of demand on the receiver, who would need to make sure that messages are being played out according to timestamps, while the absolute latency will indeed become even higher.

The approach does however achieve that things will remain to be somewhat usable even if there are larger amounts of data to be sent: The approximately 50 single messages combined in one BLE packet will all together take ~ 100 +- 15 milliseconds to make it to the other side. Each of them sent in an extra BLE packet - as Windows will do - would take 50 * 15 = 750ms.

To illustrate that with a real world example:

A DAW's initial data dump to a Mackie Controller may consist of up to ~300 MIDI messages. There will be lots of sysex containing LCD text, notes that set button states, CC data for encoders and timecode etc.

Logic Audio on macOS Monterey will achieve to transmit that data in a total of 28 BLE packets. There are packets containing only single messages (sysex), but most of them will consist of many running status combined messages - up to 86 per BLE packet. The total absolute time it takes to transmit that data is about 600ms. Things are in the same ballpark with Live and Reaper on macOS, the optimization obviously is in the operating system. And while not perfect it at least makes it somehow possible to run a DAW controller over Bluetooth LE on macOS.

Looking at a Windows DAW on the other hand:

Cakewalk set to use UWP MIDI and a Mackie Controller on a BLE MIDI connection sends a total of 311 single MIDI messages initially. Each MIDI message uses its own BLE packet, sometimes containing no more than 2 bytes of valid MIDI data. Even sysex messages that would easily fit into the 185 byte size limit are often split into multiple packets further increasing the overhead. The total time it takes to transmit that data is about 10 seconds (Timestamps indicate a range of ~6 seconds, but things are sent in multiple bursts as if the Bluetooth stack completely blocks at points).
Now if this was a one-time initial action it might somehow be acceptable, but equally large text and button-state updates will occur whenever you change fader banks or encoder assignments. Even when things are just running and the DAW only sends timecode, audio levels and maybe some automation data to set motorfaders, the amount of data to be transmitted is not exactly neglectable. What then happens is that hundreds and thousands of packets pile up in the Windows Bluetooth stack and the controller gets further and further behind the DAW timewise. When you press stop, Cakewalk stops but the controller will continue to 'play' for seconds or even minutes depending on how long the DAW was actually running. It's just hilarious. Way to go Microsoft! (I'm already very much looking forward to having this attributed to the 'garbage Android app'. It's common knowledge after all: If something goes wrong on this planet, it must obviously be TouchDAW's fault.)

Further reading:

Here is an interesting (not overly scientific) scientific paper from the 'Interaction Lab' at McGill University in Canada:
Practical Considerations for MIDI over Bluetooth Low Energy as a Wireless Interface