Tyler, lower baud would make it worse here, there’s even less room for 200 lines a second. Liam has three separate bottlenecks.
The radio. 250 kbps is the raw air rate of 802.15.4. After framing, Zigbee network and APS headers, acknowledgements, retries and channel access, real application throughput for unicast is in the tens of kbps. Each RF packet carries around 80 bytes of payload at most, less with encryption. 20 kbps is roughly what everyone measures.
The serial side. In transparent mode the XBee buffers your bytes and sends a packet when it goes quiet for a moment or the buffer fills. At 115200 in, ~20 kbps out, the buffer overflows and bytes are lost, which is your half lines. Turn on CTS flow control (D7) and honour it in the sketch, or better, switch to API mode and send binary frames: pack 10 samples (3 × int16 each) into one 60-byte frame.
Hermetry. Publishing each sample as its own message is 200 messages a second from one device. The default profile limits are 10 messages a second and 200 data points a second, go over them and owners get a notice, keep going over and the session gets closed, so those are your warnings. Even batched, 600 values a second is far more than the per-device point limit and the organisation’s per-minute data points.
For a fan rig, compute features on the Pi: per axis RMS and peak every second, maybe crest factor. That’s 6 to 9 values in one message per second, comfortably inside the limits, and a much more useful chart than raw g values.
Limits are on MQTT under Limits.