У-у-у, как все категорично! И порядком запущено HEX-формат позволяет на выходе компиляции/линковки получать индексированные массивы с расположением по любому адресу, а BIN - только непрерывные линейные потоки. Вот элементарный пример, оттранслируйте его ассемблером и создайте HEX и BIN линкером - получите файлы HEX длиной в сотню байт и BIN длиной в 4 гигабайта:
org 0
db 12h
org 0FFFFFFFFh
db 34h
В этом BIN-файле длиной в 4 гигабайта самый первый байт будет равен 0х12, а самый последний - 0х34. Между ними будет 2^32-2 нулевых байт. Только не надо сразу говорить, что такого не бывает и никому не нужно - и бывает, и нужно: есть, например, такие МК, у которых конфигурационные байты (или так называемые Fuse Bits/Bytes) расположены у верхней границы адресного пространства Flash. Но и это еще не все - иногда возникает необходимость сделать "заплатку" во Flash по определенному адресу, а исходников нет - какой тогда BIN прикажете генерировать и как объяснять программатору, по какому адресу его писать в живой МК? А с HEX все просто - можно создать файл хоть на один байт и отдать его программатору, который положит его по указанному адресу.
Так что не следует хоронить "литеральное представление" - оно просто не имеет адекватной двоичной замены