ARM, RISC-V контроллеры

Ты не с того конца C++ рассматриваешь. Обычно сразу начинают с ООП. Это не верно. C++ -- мультипарадигмальный язык программирования. ООП -- это не краеугольный камень и не серебряная пуля. Но даже ООП имеет преимущества, т.к. позволяет упорядочить архитектуру, уменьшить число ошибок. Я бы во главу угла поставил метапрограммирование и программирование в пространстве типов, и то, что C++ позволяет получить высокоэффективный код, что критично для embedded. И уменьшить число 

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

Вообще ООП не надо недооценивать. Оно позволяет определять свои абстракции, свои операции над этими абстракциями и из таких кирпичиков конструировать более сложные абстракции. Попытка то же самое сделать на C в общем возможна, но обрастает излишними для программиста техническими подробностями и провоцирует на ошибки. На самом деле ты сейчас и ООП вовсю используешь, неявно, просто не задумываешься над этим.

Мне не нравится слово "объект" или "класс", и поэтому термин ООП. От самого термина веет древним C++ из суровых 90-х, или Turbo-паскалем (Delphi) и литературой из тех же времён. Где писали TObject от которого наследовали чего-нибудь и объясняли что такое три кита ООП (наследование, инкапсуляция, полиморфизм). По-моему это очень однобокий подход исключительно с одной стороны. На самом деле суть отнюдь ни в одном из трёх китов, а в том, что поведение программа, да сама сгенерированная программа управляется или определяется типом. Тип не обязательно класс, и не обязательно машинный тип данных (такой как uint32_t). Тип это несколько более широкое понятие (в него кстати могут входить указатели на функции, указатели вообще, ссылки, левые и правые, сами функции, перечисления (enums)... Важно понимать, что оно вообще совершенно ортогонально всему остальному. Тип -- это такая сущность известная компилятору в момент компиляции. Компилятор различает разные типы, позволяет определять новые типы, у типа есть свои определённые свойства, и работа компилятора может управляться типами. Вот суть! В зависимости от типа можно получить или одну функцию, или другую, одно определение структуры, или другое, одни константы или другие, и даже другие разные типы... Это называется статический полиморфизм. Когда компиляция управляется типами. Когда программа может быть написана в пространстве типов, когда она вычисляется в момент компиляции и управляет тем, какой в итоге код, как бы на обычном C, будет сгенерирован. Вот это один из краеугольных камней C++, это почему возможна эффективная генерация кода, невозможная в других языках, которые диспетчеризацию методов, как они это называют, откладывают до момента исполнения. Это кстати ещё причина, почему C++ позволяет надёжный код: компилятор в определённом роде даёт гарантию, что код по крайней мере исполнится, а не выкинет какой-нибудь фокус в рантайме и всё нужно тестировать (как с языками с динамической типизацией).

Обычно когда учат C++ начинают с классического ООП, трёх китов, начинают всё делить на классы, наследовать, а оно на практике всё это не нужно часто. Верней нужно, но не для того, как это описывается в литературе. Нужно вот именно то, о чём я пишу выше: нужно уметь строить свои кирпичики, причём такие, из которых можно сложить эффективный код, и который практически сразу заработает без отладки. C++ легко позволяет вводить свои абстракции и из них строить программу.

Потом C++ позволяет реализовать вещи невозможные в C, что обуславливает просто другую архитектуру программы, другие подходы к проектированию, программированию. Становится легко дробить задачу на составные кирпичики, их отлаживать по отдельности (юнит-тестами), и из них собирать более сложные конструкции которые потом сами работают, без отладчика. В голом C что-то сложное рискует просто рухнуть под весом собственной сложности. Кажущимися простыми вещи в C++ могут оказаться неимоверно сложными если их переписать на C. Просто при подходе с обратной стороны, на C просто сложностей избегают. Но на самом деле сложность же не в языке, а в задаче. Там всегда одинаковое количество сложности, просто C++ её выворачивает наружу, делает видимой (это ответ на вопрос, почему на C++ напишут вечно какую-то страшную уйму кода для тривиальных вещей).