Потому что так гласит стандарт IEEE802.3
На самом деле все просто, при таком максимальном размере датаграммы она достаточно маленькая что бы время ее доставки было не критичным (особенно в случае потерь), но и достаточно большая что бы минимизировать оверхэд на канальном уровне.
Предположим что мы хотим послать IP датаграмму в 1500 байт. Это мы еще находимся на третьем уровне модели OSI. Теперь идем на второй, запаковываем датаграмму в ethernet-фрейм, то есть добавляем еще 26 байт, итого имеем фрейм размером в 1526 байт. Так же между всеми фреймами есть еще 12-ти байтный зазор, что бы различать где кончается один фрейм и начинается другой. То есть на каждую датаграмму в 1500 байт мы передаем фрейм в 1538 байт.
Давайте пока не будем отвлекаться на всякие Fast Ethernet и примим что скорость нашего Ethernet - 10mbps. Посчитаем сколько фреймов может передаваться в секунду:
10 Mbps / 1538 байт = 812.74 фреймов / секунду.
Имея количество фреймов в секунду мы можем прикинуть, при каком размере сколько будет идти наша датаграмма и какова будет полезная нагрузка на канал:
812.74 * 1500 = 9 765 625 bps или ~9.7Mbps что есть ~97% заполнения канала. Логично что если повысить MTU то и полезная нагрузка будет больше, но тут стоит просто иметь в виду еще и потери пакетов и прочее. В этом плане маленькие пакеты лучше, в итоге приходим к компромису.
Конечно с тех пор много чего поменялось, но суть остается та же. Выбираем размер пакета по оверхэду и вероятности потерь.
Рекомендую почитать:
en.wikipedia.org/wiki/Jumbo_frame 
