Средства и методы разработки

Затем, что текстовый протокол проще наблюдается и отлаживается (с помощью готовых программ), текстовый протокол вообще обычно проще устроен (проще синтаксис, ввиду доступности "внеполосных символов", в бинарном же начинаются массовые ограничения на разрядность или ширину полей, нужны указатели ширины поля, в "формате" может быть не заложено возможности расширения новыми функциями и т.п.) Наиболее толковая реализация бинарного протокола -- это ASN.1 + BER. Она сложней самодельного SET PAUSE=50. Она всё равно имеет ТЕКСТОВОЕ представление грамматики (для компилятора и, одновременно, для человека). Конечно, если зацикливаться на ассемблере и AVR, то этого не видно. А парсер туда и обратно всё равно придётся писать для отладки. И самое главное, большой разницы между текстом и не-текстом вообще нет на самом деле. И разбор бинарных данных с чужой платформы и того же BER превращается в такой же парсер, как для текста примерно, где-то чуть проще, где-то сложней. И отдельная песня с float'ами, более-менее считываемыми scanf'ом. Да, чисто бинарный протокол аж на 50% эффективней... до первого сжатия zip'ом текстового. Потом всё наоборот, примеры я приводил. Спорить действительно не о чём. Ты дальше собстенного носа не видишь. В мире полно текстовых протоколов, и отнюдь не от чьей-то дурости. Бинарные протоколы нужны и важны, но для специфичных же применений, вроде сжатого видео, звука и т.п., где размер действительно имеет значение, где экономия не 20 байтов и 200 тактов, а имеет действительно существенное значение. Пример -- GPS. В сигнале со спутника текстовый протокол -- дикая избыточность. А между компьютером и приёмником даже 1000% избыточность уже не имеет никакого значения.