> 2) частично ок. Разница в нескольких мегабайтах с C++.

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

> 3) на C обычно пишут легковесные библиотеки, которые ориентируют под встраивание на
> других языках.

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

> Впрочем, и на C++ писать никто не мешает, хотя придётся экспорты явно прописывать.

На C++ либы писать обломно, разве что интерфейс делать потом сишный. Иначе тем что получилось только из плюсов и получится пользоваться. Что все же снижает ценность такой либы.

> 4) принципиально неверно. Приделать кодогенерацию под новую архитектуру в gcc за месяц,
> может быть, реально. Сделать компилятор современного C за месяц - не реально.

Современного, не современного, а несколько простых наколенных компилеров в природе есть. По оптимизации они конечно и близко не стояли к gcc, зато один из таких позволяет покомпилить даже в JSовом эмуляторе с линуксом в браузере. GCC со всеми наворотами там был бы великоват - вкачивать столько в браузер - браузеру плохо станет.

> Да и ассемблер под новую архитектуру может и не существовать.
> Зачем он нужен при наличии высокоуровневого компилятора?

Фееричное ламерство. Для начала он может быть нужен для низкоуровневой раскрутки системы. После power up - далеко не любой процессор вообще можно средствами одного только си привести в рабочее состояние. Си например не позволяет работать напрямую с регистрами которые в памяти не видно.

Что-то такое ARM попробовал, в Cortex. Их можно запустить гольным си, без асма. Я проверял. Но есть нюанс. Проц стартует с выключенными прерываниями. Фэйл в том что регистр где разрешаются прерывания и исключения - не memory mapped. И адресуется только специальной ассемблерной инструкцией. Процессор без прерываний - не совсем полноценный для нормальной работы системы. И вот сишники чертыхаются но все же пишут "volatile asm ... " :). Потом может и уталкивают в компилерную библу, с глаз долой, как builtin-типа. Но если бы компилер это не умел - все бы сделали дружный фэйспалм и застряли на этапе попытки загрузить процессор и убедить его более-менее полноценно работать так как мы привыкли.

> функций, когда за пределами C он просто везде находится в стандартных
> библиотеках.

При этом на встраиваемых штуках типа МК это источник проблем - куча сложного малопредсказуемого кода. МК часто ставят в достаточно ответственные места, отвечать за черти-чей код мегабайтами мало кто хочет, поэтому так откровенно совать голову в петлю будет редкий эмбедер. А си что, он простой и предсказуемый, мест для лажи там относительно немного, они известные, кому было сильно надо надежность - придумали наборы правил типа MISRA C, зарубающие многие виды ошибок. А что, хотите чтобы програмер сэкономил силенок в ECU, ценой потери предсказумости? Подумаешь, ECU перепутает - сильнее или слабее газанули, например. Ну попадет какой-то лох в ДТП, главное машину с своим ECU не купить ненароком :)