0) Не советую быть fan'ом.1) Сочетание всех или части перечисленных путей, а также simplicity и security through diversity (сюда могут входить такие вещи как ASLR, но также и такие как использование редкой OS). В порядке важности я бы их расставил примерно так: simplicity, design, isolation, diversity, obscurity. Причем obscurity уровня конкретного внедрения, а не уровня продукта.
Насчет design (хорошо продуманные API, качественный код без багов) vs. isolation (privilege separation), вот интересное сравнение от DJB, где он как-бы пришел к выводу что privsep в qmail мало что давал (так как для пользователей qmail важна конфиденциальность и т.д. e-mail, а не только невозможность атакующего получить root), а вот хороший дизайн был важен - https://cr.yp.to/papers.html#qmailsec - но это одно субъективное мнение с точки зрения мейнтейнера, которому отвечать за свой проект. Ему действительно пришлось бы отвечать за любой баг. С точки зрения сисадмина или владельца бизнеса, как бы e-mail ни был важен, на том же оборудовании может быть и что-то еще важное (и даже если оно менее важное, то его компрометация это всё равно дополнительный ущерб), поэтому изоляция тоже важна.
Также, играет роль простота. Если дизайн простой, то там меньше чего и менее важно изолировать. И наоборот, если сложный, то изоляция - это способ научиться любить атомную бомбу (в данном случае - систему настолько сложную, что провести ее аудит и быть сколько-нибудь уверенным в том что ничего важного не упущено, нереально) и, условно говоря, не беспокоиться. На том же QubesOS, если в качестве гостевых систем взяты Fedora, то обезопасить их как-либо кроме как изоляцией не реалистично. Реально же беспокоиться всё равно есть о чем - об атаках внутри VM (например, одно злонамеренное e-mail сообщение приведет к утечке остальных), а также о бекдорах в той же Fedora (где разработчиков очень много, а значит и легко скомпрометировать доступ хотя бы одного из них), которые могут прилететь с обновлением одновременно во все VM (если их наивно обновлять-таки - типа, best practice и всё такое).
Owl на dom0 в Qubes по-моему не имеет смысла. Owl отличается разграничением привилегий внутри системы, а в нынешней модели угроз Qubes это не актуально, особенно на dom0. Owl внутри VM в Qubes имеет чуть больше смысла - если неудобно и слишком затратно на каждую мелкую изолируемую под-задачу использовать отдельную VM, то можно внутри Qubes'овой VM еще иметь несколько разграниченных аккаунтов и/или OpenVZ контейнеров.
1,2) Я не считаю универсально более правильным ни один из вариантов. Всё зависит от задачи и обстоятельств. В Owl, мы вынужденно выбрали RPM, чтобы быть хоть как-то пакетно-совместимыми с тогдашними дистрибутивами. Да и сам выбор Linux'а за основу тоже был сделан несмотря на понимание недостатков. Делали то, что считали займет свою нишу. Не хотели повторять то, что уже неплохо делали другие (*BSD).
3) Воспроизводимость сборок важна, если ей пользоваться, и не важна если нет. Пока ей мало кто пользуется, она мало важна, но направление это потенциально важное и наличие воспроизводимости (с планом этой воспроизводимостью либо пользоваться самим, либо доверять кому-то третьему) вполне может стать одним из критериев при выборе системы.
