Минус этого переноса очевиден. Рушится базовая система, необходимая для административных действий в случае проблем с загрузкой.
Восполнить это можно двумя способами, либо раздуть initramfs до уровня базовой системы с удобной оболочкой, дисковыми и сетевыми утилитами, либо держать /usr в самой конревой файловой системе. У обоих способов есть серьезные недостатки и пойти на это можно, если преимущества их перевешивают.

Преимущества по Поттерингу.

    * В настоящее время разные дистрибутивы Linux и Unix-системы по разному формируют состав /bin и /usr/bin. Перенос всех исполняемых файлов в /usr/bin и наполнение /bin через символические ссылки позволит избежать путаницы и сохранить совместимость с ранее практикуемым методом.

Во-первых не факт, что все дистрибутивы и юникс системы последуют призыву Портинга в светлое будущее. Во-вторых, даже если так произойдет, желаемой унификации не будет по причене разного подхода к расположению и содержанию конфигов. К примеру один и тот же сетевой /usr монтируется на станциях разными дистрибутивами. В одном конфиги в /etc/program, в другом в /etc/program.conf.

    * Все устанавливаемые из RPM-пакетов неизменные компоненты будут сосредоточены только внутри раздела /usr и не будут встречаться за его пределами, что позволит упростить организацию бездисковых систем и повысит их безопасность - для работы достаточно будет экспортировать в режиме только для чтения раздел /usr и централизованно обновлять его, не заботясь о необходимости синхронизации содержимого каталогов /bin, /sbin и /lib. В корне останутся только файлы, связанные с загрузкой и специфичные для текущей машины данные, например, файлы конфигурации, логи и файлы с меняющимися данными (/etc, /root, /var, /run).

Вот здесь все наоборот. Кроме /usr придется монтировать как минумум /etc.
Сейчас же, например, в ltsp, монтируется только один корень или по nfs ro или, что чаще, nbd + squashfs и накладывается на фс в оперативной памяти. Это и функциональнее, и совершеннее, и не менее безопасно.

    * Возможность использования нескольких разделов /usr для загрузки разных версий или состояний дистрибутива. Например, в процессе обновления можно сохранить старое содержимое в отдельном разделе и вернуться на него в случае проблем. Возможна также реализация схемы, при которой имеется две копии содержимого /usr: активная копия монтируется в режиме только для чтения, а в неактивную устанавливается обновление, после чего директории меняются местами и синхронизируются;

Приехали. Обновили /usr1. При этом изменился /etc. Вернулись на /usr0. И "великий" systemd, прочитав конфиг, пытается грузить не существующие программы. Возможно, systemd будет хранить конфиги в другом месте, но проблема не сильно меняется.

    * Упрощение формирования гостевых окружений для систем виртуализации - достаточно монтировать внутри виртуальных окружений системный раздел /usr в режиме только для чтения. При этом автоматически решаются проблемы с обновлением начинки гостевых систем и существенно экономится дисковое пространство;

/usr и сейчас можно монтировать только для чтения. Но, кроме этого /bin можно монтировать, а можно использовать и свой оригинальный, что дает дополнительную гибкость.

Доводы передового разработчика напоминают отписку для дураков. Думаю, большинство дистрибутивов в этом вопросе не пойдут стройными рядами за Федорой.