Почему почти все поля, в ms sql имеют тип binary?
особенно непонятно, почему так, для булево и для уникального идентификатора.

А Вам зачем это знать?

Для общего развития.
Явно-же там есть какая-то причина, и возможно это даст лучшее понимание принципов работы БД.

(0) Потому что у 1С своя кодировка строк (4 байта на символ), чисел, дат и даже для булево
Изначально хотели сделать Истина, Ложь или Неопределено (аля NULL) но потом забили
И вот с тех времен и тянется

Не забываем,что поддерживается несколько sql-сервнров.

А как вы считаете, то что из запроса нет возможности получить идентификатор элемента метаданных, связанно с тем, что он хранится в особом формате? тоесть, на уровне платформы, нужно выполнить какой-то код по преобразованию, а просто sql запросом не вытянешь

Правильно, ли я понимаю, что логика генерация гуида, какая-то такая:
- генерируем новый ГУИД строкового типа.
- поскольку у ГУИДА, символы от 0 до f, то можем каждый символ записать как байтовое представление, без кодирования/декодирования. Хранения в байтовом виде добавляет производительности.
- при записи переставляются местами куски гуида, чтобы усложнить сторонним программам работать с данными напрямую, нарушая политику лицензионости
?

И если бы использовался тип MS SQL uniqueidentifier, то он был-бы такой-же быстрый как binary ?

(6) Что такое идентификатор элемента метаданных?
Если имеется ввиду данных, то ставь 22 платформу
если нужен идентификатор метаданных- то выгружай конфигурация в XML и парсь

Потому что любят они велосипеды с квадратными колесами. Переносимость можно было обеспечить и без этого - просто следовать стандарту SQL-92 и всё.

(7)
GUID это просто 16 байтов - https://ru.wikipedia.org/wiki/UUID

(16) в запросе с платформы 8.3.23 можно получить уникальный идентификатор

* (6)

(12) с 8.3.22 уже
https://wonderland.v8.1c.ru/blog/poluchenie-unikalnogo-identifikatora-obekta-iz-ssylki-v-zaprose/