Thanks for pointing out the delays in the Acceleration examples. Those have been changed to use Been.sleep instead.
Delay does not allow the Bean to completely sleep. The Arduino will stay awake and will drain your battery much quicker. Bean.sleep() will allow the Arduino to sleep, reducing your overall power consumption by a great margin. I recommend using Bean.sleep() in place of Bean.delay(), unless you need to delay less than 5ms.
Regarding the issues people are seeing when looping through lots of serial.write commands--the Bean can keep up fairly well, but needs a chance to catch up on the BLE end. Sending a large amount of serial data will tie up your resources quickly, as the UART communication to the LBM313 communicates faster than BLE can send data out. If all of the allotted BLE buffers are constantly full, communication from the client can be difficult. We're writing a primer for this stuff currently that will give some guidance on how to maintain good throughput safely. We're also looking into ways to make tying up the Bean through serial writes less possible, or not possible at all (throttling UART, etc.). In the meantime it's best to throttle your data a bit in your sketch anyway. I'd definitely place a short delay after every four short (<15 bytes) serial write commands or so, say 5ms or more. Thanks again to @Nonsanity and all that helped those that ran into this issue recover their Bean.