> Затем что бы основная задача не впадала в ступор и имела гарантированное
> время отклика.

Сильно зависит от задачи и времени отклика. Ясен пень, щелкать обмотками BLDC мотора из линуха через GPIO было бы полным кретинизмом. Зато, например, реле которое рыбам свет в аквариуме врубает - может тупить плюс-минус пять секунд и всем будет сильно до лампочки на этот факт, зато возможность порулить релюшкой по wi-fi через вебмордочку народу вполне может понравиться. Удобно же когда ближайшая мобила с wi-fi или комп - пульт управления всяким добром в доме до кучи.

> Вот именно, то что элементарно делается на atmega, реализовать на мощном хорошем
> универсальном проце с ОС иногда  сильно сложнее. Тот же софтовый PWM.

Именно софтовый - да, к времянкам требователен. Но вообще-то это настолько требовательный процесс, что даже на атмеле писать программу становится довольно геморно и так обычно предпочитают не делать. Ну то-есть если это будет единственная функция чипа - тогда не проблема. А если он что-то еще делает - придется следить чтобы это "что-то еще" не отобрало управление на время больше парехода между состояниями PWM. По нормальному это уже таймер просит и прерывания. А раз пошла такая пьянка... посмотрите как STM32 аппаратный PWM сделали. Немного допилив железо таймера оно становится совсем аппаратным и чертовски гибким. И в достаточно большом количестве, чтобы в 99% случаев не париться такими утонченными извращениями...

> Я так понимаю, открыть файл на запись  /sys/devices/... и записывать в
> него состояния, против одной строки типа PORTB = _BV(PB1);

Я не спорю, это медленнее и нагрузка на проц при активном дерге лапок выше. Но как я уже сказал, дернуть полевик который какой-нибудь релюхой врубит рыбам свет в аквариуме - выше крыши. Более того - скорости работы всего этого хватит для большинства задач, ибо с точки зрения человека что 1 микорсекунда, что 10 миллисекунд - не больно громадная разница.