Well, base packet overhead is about 1-3 bytes random waiting time, 1 start of header byte, 1 start of data byte, 2 bytes of checksum, and 1 byte that marks the end.
If you just use it as a hobbyist/low grade replacement for CANbus, with one byte channel names and a few bytes of data the performance will be a little less than canbus.
If you use UUID channels, then you add 16 bytes(plus a few more if any of the bytes in the uuid are a control character needing escaping), and with an eight byte payload you would be up to 35 bytes, a little more than twice the length of a modbus read request you get about 35 bytes.
Its not an actual ascii protocol, it just requires escaping your control bytes which only adds a few percent in the average case
Compared to doubling the message like sending data in hex would.
The advantage comes when you have user inputs that rarely change, you can send the "button pressed" signal only when needed, and the "knob turned" signal only when the knob is turning.
But for sending commands to devices quickly it is much slower. Bulk data transfer speeds are slightly better than can and comprable to i2c because you can have packets with 100+ data bytes.
The UUID channels are a huge speed penalty, so there needs to be a standard way of assigning one byte channels to devices.