>То, о чём вы говорите, это Unix way 1970-х. Тогда было только
>CLI only. Всё течёт, всё изменяется, и Unix way претерпел изменения.
>И как сочетать парадигму 1970-х с GUI приложениями? Вы же для
>гуевых прог не будете набирать:
>proga1 --opt1 | proga2 --opt2 | proga3 | ...
>Там как-то плагины более уместны.

Unix way это не только принцип "программа-для-одной-функции", но и то, о чем вы совершенно справедливо вспомнили - простое взаимодействие программ между собой (пайпы это лишь один из вариантов). Причем, это надо сделать так, чтобы программу можно было использовать саму по себе (1), в сочетании с другой программой (2), в составе (или под управлением) другой программы (3), причем в последнем случае опять таки надо обеспечить, чтобы получившаяся система соответствовала всем трем этим принципам. Это, с одной стороны, позволяет строить системы большой сложности и функциональности, а с другой позволяет как раз делать более простыми (и, как правило, за счет этого более надежными) составные части. Причем, обратите внимание, это относится как к CLI, так и к GUI! Да, в CLI и GUI используются обычно разные механизмы (хотя никто не мешает, например, GUI-программе иметь развитый интерфейс командной строки), но принципы остаются в силе. Плагины, это немного не то. Во-первых, плагины возможно использовать только по 3-му варианту (в составе одной базовой "хостовой" программы). Во-вторых, чтобы написать плагин надо разбираться не только в предметной области, но и в API, предоставляемым "хостовым" приложением (а он тоже может быть: нестандартным, недостаточно функциональным, сильно меняться по прихоти разработчика основной программы и т. п.), а это сильно сужает community, так как многим грамотным разработчикам будет неинтересно (мягко выражаясь) копаться в каком-то "левом" API и глюках "хостового" приложения.

Увлекся... В общем, имхо, парадигмы меняются, а unix-way остается, так как само понятие более общее. Это как бы общий принцип, которому либо следуешь, либо нет, независимо от парадигм, интерфейсов и т. д.