For some applications, text based protocols aren't very well suited, for instance because of space constraints. Protocols that present data such as integer values etc as binary values are usually much more compact and can be processed much more efficiently than protocols that represent all data as ASCII strings no matter what the underlying data type is.
There isn't really the method of devising binary representation protocols; there are just a few techniques you'll encounter quite often.
For instance, it is very common to represent integer values as two's complement numbers using big-endian byte order (i.e. the most significant byte first).7.3 It is quite important for a network protocol to define things like this, otherwise machines with different sizes for integers, or with a different byte order, will not be able to talk to one another. Thus, no matter how your machine represents integers natively, it has to convert them to the canonical or network representation defined by the protocol before it can send them. Likewise, when it receives data from the network, it has to convert it from the canonical representation to its native one. The same is true for all other data types; be it strings, floating point numbers or complex types such as linked lists of structs (of course, not all protocols try to do things such as sending linked lists across the network, but some do!). The process of converting data objects to the network representation is frequently called serialization because potentially complex data structures are converted to a sequence of bytes. The reverse operation (converting from network representation to host presentation) is called deserialization.
As you might expect, encoding complex data types means quite a bit of code complexity during serialization and deserialization. And of course, there's a potential for security bugs.