I have had nothing but issues with B4A and its communication stack libraries. It is all over the place when it comes to timing, and I think its because it is running on the main thread and in the message queue along with everything else.
For example on Bluetooth classic, I can do Asyncstreams.write and then a sleep, and then another asyncstreams.write, and sometimes they get the proper delay, but sometimes they get jammed together. Packet timing is like going shooting nearsighted without your glasses. Ultimately I had to create a class and use a software FIFO to handle communication traffic to allow everything to return to prevent that "jamming" effect, But this doesn't fix the timing variances though.
So you are not alone in this. The only way to fix it in the above scenario is to return from literally everything and allow the message queue to process. But if background tasks get tossed on the same queue, it increases the delay. AS above.
I wonder if there is a way to move the Bluetooth library/stack over to its own thread, so the next experiment would be to use the threading library, launch a class in another thread with the bluetooth stuff, and then setup a software FIFO between the threads.
Anyways the bottom line from my experience is "Write" never completes until the message queue is free for it to do so.