1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему.
2. Кроме времени еще важна и память. На клауде можно не боятся, но на хостинге процесс могут затоптать за оверхед по памяти. 5000 тыс конечно не число, но я бы предусмотрел бы какое-нибудь порционное скармливание данных по чуть-чуть. Не знаю наверняка, но скорее всего так оно и есть. Печально, если нет :) Ну и запускать такое нужно не через веб-морду. В консоли ограничений на выполнение php точно нет.
3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах
4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно.
P.S. Ответы пишу не с пустой головы. Работаю сейчас с проектом, у которого под миллион уников в сутки и отдельные таблицы весят под 10 гб, не считая десятков миллионов записей в nosql-хранилищах. Это все добро конечно же не на modx, но подходы в крупных проектах все равно одни и те же.