Дело в том, что и ia32 и x64 принадлежат, как правило, платформе x86_64 и используются только на ней (про исключения, вопплощенные в железе - планшеты i586/ia32, я слышал но вживую не видел).
К примеру, машины, на которые производитель устанавливал ради экономии памяти и дискового пространства Windows10 32-bit (и как следствие UEFI ia32, так как только она по спецификации может загружать 32-bit код) были построены на базе Atom z8xxx (x86_64).

Действительно ли так критично хранить их раздельно?

Я подозреваю, что модули для других архитектур тоже появятся. Было бы странным носить их все вместе.

Получается, проблема в существовании 64-битного железа, у которого UEFI ia32?

Конечно, мне кажется, что наличие ia32 в отдельном пакете помогло бы обрабатывать эту ситуацию в инсталляторе.

Тем не менее, очень странно хранить 32-битные модули в /usr/lib64.

(Ответ для Vitaly Lipatov на комментарий #2)
> Я подозреваю, что модули для других архитектур тоже появятся. Было бы
> странным носить их все вместе.

Никто не собирается носить их вместе. И aa64 (хоть там пока и путаница с именованием EFI-бинарника, будем исправлять), и ppc64le (ieee1275) ходят сами по себе.

> Получается, проблема в существовании 64-битного железа, у которого UEFI ia32?

Ну, в общем-то, да.

> Конечно, мне кажется, что наличие ia32 в отдельном пакете помогло бы
> обрабатывать эту ситуацию в инсталляторе.
> 
> Тем не менее, очень странно хранить 32-битные модули в /usr/lib64.

Это несоответствие можно исправить, но нужно посмотреть, как оно отразится на mkimage и mkimage-profiles.
При переносе бинарника EFI ia32 в /usr/lib/efi, нужно будет править процедуру подписи pesign. 
Если это сейчас ничему срочному не мешает - займусь этим позже.