In planning control systems, I avoid binary messages when I can. The most significant binary data consideration is byte ordering issues. The processor's Endian order is a design decision of the processor's manufacturer. This decision defines the memory ordering of the bytes of their system. Typically, the lingo is Little Endian or Big Endian (although a few architectures exist that don't fall into either of these categories). Messages that rely on sending binary information from one system to another unknown system must define which Endian order the data will be sent in. A 4-byte binary number sent from an Intel architecture to a PPC architecture must have the four bytes reversed to restore the numeric representation. Byte ordering considerations are not an issue if the number is sent as ASCII or if a common processor architecture is used. However, assumptions of common processor architecture might create long-term support issues if the architecture changes sometime during the life cycle of the system.
Another binary message issue is binary compatibility. Most computers use a two's complement integer and an IEEE 754 floating-point format. These are well-used or industry-defined formats that specify the notation of the stored computer number. It's generally safe to assume most computers use two's complement and IEEE 754. However, I've used computers with one's complement integers and a unique floating-point format that barely resembles the IEEE 754 floating format. These architectures will have conversion algorithms, and they will require additional overhead.