Лучше больше потоков, чем меньше, не важно сколько параллельных задач собирает. Обычно хватает EMERGE_DEFAULT_OPTS="-j1" и MAKEOPTS="-j$(( $(nproc) + 1 ))" (это -j у make не у emerge), или -j2 чтобы скрыть лог. Я не знаю, что там может быть непонятно, всё в манах есть, он запускает параллельные независимые задачи (если пакет зависит от других пакетов то они обязаны быть собраны перед ним). Должна быть полная утилизация, если ресурсов не хватит это всё ещё на порядки эффективнее чем когда ресурсы простаивают. Какие там сложности, рекомендация всегда была одна.

И кстати, -O3 не подходит, он в основном вызывает замедление кода раза в 2 на гцц. Поэтому мне всегда смешно, когда похороникс тестирует гцц с -O3. При этом, его очень любят хардкодить во всякие сомнительные программы вроде unrar. Чтобы был толк от этих оптимизаций, надо собирать с PGO, вот тогда гцц действительно побеждает по производительности и эффективности бинарей, где это возможно. Только это всё никак не влияет на отзывчивость, только на производительность кода на задачах, которые не имеют значения для большинства пользователей (они не занимаются пакетной обработкой и 3-30% разницы им не интересно).

У меня без проблем обновляется, пару раз обновлял через 5 лет, были небольшие сложности из-за изменений в дистрибутиве, но ничего серьёзного. Раз в полгода вообще норм, как раз поднакопятся обновления чтобы за ночь скомпилировалось и меньше проблем с циклическими зависимостями.

И насчёт монолитного ядра у тебя какие-то заблуждения, оно только монолитное в линуксе. Выбор собирать часть компонентов модулями или же вкомпилить сразу в ядро никак не влияет в рантайме, влияет только на то, что всегда будет в ядре когда оно загрузится и что будет подгружаться по мере необходимости. Особенно актуально, когда не используется initramfs и ядро грузится напрямую из uefi.