> А в случае обычного BIOS и MBR это вообще не важно.

если ты готов и дальше работать на своем IBM PC XT - то не важно.

> Код загрузчика MBR вообще 16-и битный и ничего, всё прекрасно работает.

очень неважно он работает - например, эта MBR на больших дисках давно фуфловая, а значит, всегда есть риск, что какой-нибудь глупый софт тех же времен примет ее за чистую монету и что-то изгадит.
С чтением за пределами 8го терабайта у этого кода полная беда (и с четвертым-то успех частичен), не смотря на все костыли и подпорки в виде lba и еще больше lba, здравствуйте бут-партишны в "начале" (того, у чего и начала-то никакого скоро не будет). С native 4k дисками просто полная задница, настолько, что все попытки вывести их на рынок юзерского сегмента провалились.

и это только диски. А еще есть сетевые карты, современные, под тяжелую нагрузку - которым вообще хрен объяснишь, как, с их внутренней мультиядерностью, жить на полузапустившемся процессоре. И еще много чего странного есть.

И поддерживать эту легаси уже давно всем надоело.

> Зато сколько нестандартных костылей с загрузчиками придумали линуксоиды.

именно потому, что "все прекрасно работало". Если, конечно, у тебя ms-dos 3.3, иначе как-то разом становилось менее прекрасно.
Да, про прелесть "умести начальный загрузчик в 512 байт минус данные и метки или хрен его вообще знает, куда тебе его девать" я забыл упомянуть.

все эти и многие другие проблемы как раз и решает uefi. Не нужно умещаться в 512 байт, и потом еще в те 640 которых should be enough, совершенно все равно в какой части какого диска лежит efi-раздел и лежит ли вообще (если нет, возьмем загрузчик с tftp, если он большой - с http тоже можем), не нужно страдать с недозапущенным процессором в 16битном режиме, логично, а не через задницу и неполнофункционально встраивается удаленное управление загрузкой. Но дятлы продолжают упорно долбить "дайте нам биос и int13".