Я думаю что я знаю почему. Замечу что это не инсайдерская информация — я основываюсь только на моём опыте разработки приложений под WP и если внимательно смотреть на само приложение, то можно увидеть что именно работает в нём медленно (и сделать выводы, как я сейчас).

Во-первых, нам нужно понять как в WP добились их легендарной плавности интерфейса. Весь секрет в хорошей многопоточности. Для каждого приложения (и для самой ОС в целом тоже, я полагаю) есть поток называемый “поток UI”. В самой операционке этот поток также называется как поток ввода-вывода (i/o bound thread), т.е производительность зависит от задержек которые происходят во время выдачи времени процессора. Планировщик NT ядра должен быть настроен так чтобы всегда давать потоку нужное кол-во процессорного времени — 60 раз в секунду чтобы поддерживать эту самую плавность (не снижать частоту обновления UI). Короче говоря, если поток завершит свою работу за условленное ему процессорное время, то вы никогда не увидите задержки, интерфейс всегда будет отзывчивым.

Итак, потоку UI выдаются маленькие но частые порции процессорного времени. Что же происходит во время огромного кол-ва вычислительной работы в потоках? Заметьте что это мобильный процессор, а значит даже простые вещи вроде осмотра списка данных или какой-то LINQ фигни требуют интенсивных вычислений. И вот эти самые вычисления часто отбирают процессорное время отведённое на потоки UI, которые не успевают отрисовывать интерфейс в 60 кадрах в секунду и вы видите лаги.

Итак, вам нельзя полагаться только на отведённые вам потоки UI. Что же вы делаете? Вы используете фоновые потоки, так называемые рабочие. У них нету никакого резерва на планировщике задач CPU, так что вам не надо беспокоиться насчёт производительности UI что будут затронуты вашей работой с этими потоками. Хорошо написанное приложение всегда использует эти более лёгкие потоки для того чтобы уменьшить количество вычислений.

Но теперь у нас есть проблемка. Чтобы поддерживать равновесие между потоками UI и фоновыми процессами, команда разработчиков WP сделала так, что рабочие потоки никогда не могут затрагивать UI. Попытка сделать это — вызовет исключение. Вот в этом и заключается проблема. Вам как раз и нужна возможность влиять на UI произведёнными вычислениями. Для этого у Silverlight есть штука под названием “привязывание (связка) данных”. Что оно делает? — сохраняет ваши результаты в специальном месте. Интерфейс всегда связан с этой переменной — всегда отображает её контент (я очень упрощаю — но в целом идея понятна). Когда рабочий поток завершает работу и сохраняет результаты в специальном месте, он посылает уведомление в поток UI, который получив эти данные — обновляется. Движок уведомлений встроен в систему и вам не нужно ничего дополнительно писать, он оптимизирован, отзывчив и просто работает.

Пока вы следуете всему тому что я описал выше, то ваше приложение будет очень отзывчивым. Так вот, к чему всё это.. Я думаю что команда работающая над приложением Xbox Музыки не следовала этим правилам. Ещё есть пара-тройка причин, например частота с которой обновляются метаданные музыкальных файлов показывает, что приложение кэширует их неправильно.

Но почему разработчики MS не используют свои технологии правильно? Мне кажется, что это из-за того, что старый хаб был сделан другой командой разработчиков WP, которая создавала как технологии так и приложения, а вот новое приложение сделано командой Xbox, которые видимо ещё не набрались опыта в WP. Надеюсь что со временем они исправятся.

P.S: В ответ ему последовал ответ о том, что любой объект можно синхронизировать с UI, используя объект Dispatcher на любом из контролов, даже в Silverlight или в WinRT и что интерфейс старого хаба музыки построен на закрытом движке (он как бы нативный, и до сих пор используется в Office например).