Знать программисту необходимо двоичную или шестнадцатиричную систему счисления для выделения

Оптимизация кода - забота компилятора и прочих средств. Асм сейчас не столь актуален, как лет 30 назад, хотя остались сферы его применееия, но постоянно снижается. Кроме того, сс тут ваще ни к месту

Нет, не верно. Двоичная и шестнадцатеричная системы нужны в первую очередь для удобной манипуляции с битами.

Контроль места в ОЗУ актуален в современном мире только для микроконтроллеров. Но даже в этом случае возможностей C (не С++) обычно вполне достаточно. А можно взять, например, язык Forth и получить размер программы даже меньше, чем на ассемблере.

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

Крайне редко стоит задача свести бинарный код к минимуму. Гораздо более важны концепции сборки мусора, многопоточности. Поэтому и придумывают языки типа Go. А ассемблер -- это для бородатых дядек, которые решают узкоспециализированные задачи.

Код МОЖЕТ занимать меньше, если компилятор у C# неудачный. Хотя там вроде бы байт-код, так что оверхед всё равно будет. Но проблема в том, что на ассемблере ты сам должен контролировать всё, что берёт на себя компилятор C# или любого другого языка высокого уровня.
А двоичная и шестнадцатеричная системы — это одно и то же, просто степени двойки разные и биты группируются по одному или по четыре.

зато на ассемблере тебе самому придется заботиться о освобождении ресурсов и очистке мусора, и работать с памятью через win32 api, т. к. прямого доступа к памяти тебе не даст сама система, правда это можно обойти написав дрйвер уровня ядра и подписав сертификатом разработчика драйверов который придется покупать (веризон их продает по цене от 500 долларов в год), и левый здесь ни разу не прокатит, т. к. микрософт строго контролирует сертификацию драйверов уровня ядра :)

У Вас в знаниях мешанина. Двоичные и шестнадцатеричные системы счисления это только системы счисления, то как внешне выглядят числа 10 => 0a => 1010. Конечно связь между ними и компьютером есть, например один байт в шестнадцатеричной системе счисления всегда состоит из 2-цифр (0-9A-F), а две цифры всегда влазят в байт, на этом их связь и заканчивается.
Компилятор C# строго говоря генерирует совсем не тот же код, что и ассемблер (машинный). А промежуточный (IL), он запросто может быть меньше чем код на Ассемблере. Но его ещё предстоит скомпилировать в машинный.
Размер кода и производительность напрямую не связаны. Много чего в современном процессоре влияет на производительность. Количество выполненных инструкций, время выполнения каждой, возможность их параллельного выполнения, необходимость многопоточной синхронизации, успешность предсказания результата условий, влезаемость в кеш процессора микрокода из этих инструкций и данных используемых кодом, эффективная подгрузка данных из RAM в кеш и это вероятно ещё не всё.
Современные языки, такие как Delphi, C++, Rast, Go, C#, Java не говоря уже об интерпретируемых, генерируют и выполняют слишком много лишнего кода в угоду простоте синтаксиса, возможности повторного использования кода и выявления ошибок программиста в процессе выполнения программы. Но если взять чистый Си, собрать с максимальной оптимизацией одним модулем, да ещё и прогнать его с получением статистики ветвлений. То написать более оптимальный код будет крайне сложно. Исключения пока, что в не очень эффективном использовании семейств SIMD инструкций. Но про них вообще лучше забыть и скармливать данные видеокарте, которая способна переварить гораздо больше данных нежели SIMD.
А насчёт возможности контроля за выделением памяти, Ассемблер лучше контролирует расположение данных в памяти, что может дать некоторую прибавку к производительности кеша второго и третьего уровней. Но вероятность найти возможность которую невозможно реализовать на Си стремится к нулю. Гораздо больший шанс на это при оптимизации расположения кода, чтобы код используемый алгоритмом не был разбросан как попало, а был расположен на наименьшем числе страниц памяти. Этакая микро-дефрагментация, но современные процессоры преобразующие инструкции в микрокод вряд ли нуждаются в подобной оптимизации.

Так, что для оптимизации лучше использовать чистый Си и толстый справочник по процессору. Хотя никому особенно эта оптимизация нынче не нужна, время программиста дороже железа, скорость написания готового кода ещё дороже, а на системы конечных пользователей всем давно плевать. Исключения тут только при выпуске огромной кучи одинаковых устройств в которых благодаря оптимизации можно поставить более слабый процессор и меньше памяти.

Программистов всё больше, а работы - всё меньше. Безработных армию пополняешь. Иди учись плитку на стены класть .