> Разве что места на диске. Потреблять _много_ памяти - дурной тон даже
> для комбайнов.

Боюсь, что hello world на qt, сожрет больше памяти, чем ядро со всеми драйверами для дескотпа ;)

> Удобство, как правило, важнее гибкости. Лучше легко и просто решать несколько типовых
> задач, чем требовать возни с компоновкой модулей при любом раскладе.

Верно, но компоновать нужно по задаче - нужны кодаки - возьму ffmpeg. Нужны базовые сетевые протоколы - возьму curl. И т.д. Нет смысла компоновать слабо связанные задачи в одну библиотеку.

> Если вам нужно реализовать определенный набор функций, то где, по-вашему, будет меньший
> сумарный объем кода - в комбайне, в котором совместное использование всяких
> общих функций проще, или в десятке-другом независимых проектов?

Пример: нужен простой видео плеер с поддержкой http и выводом через opengl.
Вариант 1: ffmepg+curl+glfw.
Вариант 2: Qt(+куча зависимостей) + ffmpeg.

Где меньше сумарный объем кода?

>> Изменить в ней что-то достаточно сложно - нужно гораздо больше времени на изучение и тестирование.
> Спорно.
> Если взять комбайн и разбить его на сотню "независимых" проектов - все
> равно придется изучать вопрос в целом (если, конечно, изменяющий не PHP-обезьянка
> за миску риса, которой на все пофиг), и тестировать конечный продукт,
> поскольку полной независимости обеспечить невозможно, и баг в одном компоненте всегда
> может аукнуться в другом.

Если я правлю баг в curl, как это отразится на ffmpeg?

> Qt выбирают именно из-за его портируемости. В отличие от того же Gtk3,
> который пилят в основном под Linux.

Выбирают из-за того что он уже портирован. Портировать такой объем кода на новую платформу ради одной программы никто в здравом уме не будет.