Элементная база может быть избыточна для функциональности даже спорить не буду.
Но суть проблемы не в функциональности, а в надежности и скорости разработки.
Появление таких процессоров как LPC43xx или Vibrid кое что означает.
Разработчики этих решений в первых же строках указывают, что это драматически упрощает разработку!
Как вы думаете за счет чего?
Явно проще программировать не становится и ошибок меньше не станет... Так в чем же дело, откуда такой тренд? ...

А задачи не надо никак обзывать, они уже названы.
А перенос на задачи RTOS представлений из GPOS только запутывает суть дела.
Ибо в задачах RTOS тоже наблюдается отдельное понятие потоков, только это совсем не те потоки.

Вы явно уходите в высокие материи и термины, а я туда не хочу.

Я обратил внимание на непоследовательность Ваших суждений. На первой странице Вы красочно описали, что не используете объекты синхронизации, что пишите переменные на прямую, зная когда к ним обращаться. Но в конце вдруг заметили необходимость сервисов очередей и событий. А ведь они и есть объекты синхронизации, которые преданы Вами анафеме. И совершенно не важно, что объекты синхронизации я обозвал средствами синхронизации потоков. Ведь понятно о чем идет речь.

Ну нет, анафеме я предал мьютексы и семафоры. А синхронизацию потоков как синоним первых двух.

Хотя может быть семафоры оставлю. Пусть живут.
Дело в том, что семафоры чаще используются в реентерабельном middleware и драйверах.
Но вы это часто получаете готовым.
Реализуя же собственное приложение, чаще делаются единичные экземпляры задач с взаимодействием многие к одному.
И тут семафоры редко нужны.

мне сейчас как раз нужно реализовать нечто подобное. Где можно посмотреть пример использования poll?