В сумме $5 миллионов? Сами готовы столько выложить? )))
Если вспомнить, что ESP32-C3 стоит $1, то Вы предлагаете пятикратное удорожание!

Использование интерпретатора для GUI на высоком уровне абстракции понятно, так как там производительность кажется не важной. Но как только этим интерпретатором спускаемся немного ниже, получаем веб-страницы, способные загрузить на 100% более одного современного десктопного ядра и требующие гигабайты оперативной памяти.

>> сильно нагружает оперативную память
> Копеечный PsRam - и нет проблем.

Мало того, что само использование Python приводит к падению производительности на порядок, так предлагаете снизить производительность ещё на порядок? )))

> На ESP32 полет мысли в принципе жрет память и без скриптовых языков,
> и нередко только встроенного ОЗУ недостаточно.

Так может полёту мысли не хватает навыков реализации этих мыслей?
Я когда-то Арканоид сумел впихнуть в ATMega328 с 2К RAM, причем он был вполне играбельным.
На нескольких десятках килобайт RAM расцвели игровые приставки и ZX Spectrum.
А ESP32 заметно превосходит по возможностям Macintosh, у которого было всего 128К RAM.
Так может память жрут кривые руки и недостаток знаний? )))

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

Но в статье не стали ограничиваться экранным интерфейсом, сделав полностью OS. Я именно об этом речь и веду, что такой подход потребовал минимум ESP32-S3, тогда как реализация скриптовым, а лучше даже декларативно-скриптовым, языком, снизила бы требования до ESP8266, не говоря уже о ESP32-C3.

Тем не менее, я вполне умудрялся на RP2040 делать долгоживущие от аккумуляторов (до года на LR2032) проекты на Micropython, хотя в нем и нет глубокого сна. Просто проектирование становилось намного более сложным с т.з. железа, с полным обесточиванием компонентов через мосфеты. Большей проблемой были саморазряд аккумуляторов, а также энергоэффективность сторонних модулей. Ну и писалось это с активным применением как PIO (для LCD), так и с активным использованием регистров. Вроде еще Viper активно использовался, но сейчас уже не вспомню.

Что касается PIO, то я и не говорил нигде, что он используется для вычислительных задач. Но PIO позволяет разгрузить основной процессор при работе с периферией, хотя при этом разумеется усложняется логика приложения. Это позволяет быстрее выполнить работу и раньше усыпить микроконтроллер и периферию.

Большей проблемой зачастую при работе с Micropython является память и сборка мусора. Для необходимости эффективного использования памяти (особенно при возможной фрагментации), однозначно лучше старый добрый C/C++ (включая Arduino).

НЕ удивительно, как и Python == 666...

Не знаю, о какой сфере Вы ведете речь, но для сравнения.
У меня есть выносные датчики температуры и влажности на STM8L152C6T6 и nRF24L01+, отображающие эти показатели на LCD индикаторе и передающие данные, или при изменении этих показаний, или раз в 10 минут. Для их питания одной таблетки СR2032 хватает больше, чем на год. На любом МК, на котором можно запустить MicroPython, среднее потребление менее 1мА в этом сценарии точно не получим. А значит, СR2032 хватит дней на десять максимум. Разницу замечаете?

На мой взгляд, MicroPython на МК может быть оправдан только для единичных DIY проектов с питанием от сети. В остальных случаях на МК ему делать нечего.

Вы утверждаете, что реализация для микроконтроллеров, с их ограниченными ресурсами способна на большие оптимизации, чем cpython? Самим не смешно?