Забігаючи наперед — для AVR цілком можна писати на C++, якщо не надто розганятися. При акуратному використанні шаблонів і код не роздувається де не треба, і швидкість непогана де треба (за рахунок якраз роздування коду, але зробити це заради швидкості шаблонами може бути зручніше, ніж С-шними макросами, див, наприклад, цю тему.

А якщо писати без класів, у звичайному процедурному стилі, то і простори імен будуть, і зайвих витрат пам'яті не буде, буде «все як на С», тільки буде LibraryName::FuncName() замість LibraryName_FuncName() чи LibraryName.FuncName() у варіанті зі статичними структурами (і що красивіше — на мою думку лише питання смаку до течій AsciiArt, а не «краси коду», хіба ото у варіанті C++ можна using namespace сказати для вибору конкретної бібліотеки).

Тут пощастило, бо компілятор бачив все, бачив, що структури константні і зоптимізував роботу з константами.

А тут компілятор не міг побачити вміст цих константних структур, тому згенерував повний код.

Жертва ресурсів не така вже й велика. Якщо функції складні, то в них кілька push на початку і кілька pop в кінці зжеруть набагато більше часу, ніж той непрямий виклик через icall.
Повертаючись до С++ — виклик віртуальної функції буде ще трохи дорожчий, ніж той виклик зі структури, бо таблиця віртуальних функцій класу лежить окремо, спільна для всіх екземплярів класу.
А якщо функції не віртуальні, то у порівнянні з С практично нічого не додається. Так, перед викликом у регістрову пару буде завантажуватися вказівник на структуру даних екземпляра класу, але це навіть добре, бо у самій функції будуть звертання до полів структури зміщенням. ldd r16, Y+4, наприклад, що коротше, ніж lds r16, struct_addr+4, яке часто у таких випадках генерує компілятор, навіть якщо у коді звертання по вказівнику(!). А щоб форсувати у С-ному коді завантаження вказівника і звертання по ньому, навіть придумали макрос RELOAD.

Тепер розворот, і повертаємося до С з константними структурами у різних файлах.
Є така штука LTO (link-time optimization). Компліятор тоді у об'єктні файли кладе не готовий код, а свої внутрішні структури його опису. А лінкер тоді вже бачить всю програму як одне ціле і робить наскрізну оптимізацію. Чудово вигризає все, що може. Прошивки в діапазоні розміру 4-40 кілобайт стають на 5-7% коротшими. Бачить, що дрібні функції з іншого файлу можна вставити по місцю як inline і оптимізує їх у кожному місці окремо. Для C++ теж корисно.
Але — якщо десь було забуте volatile, то варіант з функціями в інших файлах може працювати, бо виклик зовнішньої функції спрацьовує як бар'єр пам'яті, а при LTO вони вже не «зовнішні» у цьому розумінні, і без volatile щось може «уоптимізуватися вусмерть»