Привет.
Мне, если речь идёт о связи с веб-мордой и мобильными клиентами (в перспективе не только wp) нравится в качестве бэкенда использовать asp.net mvc web api. Это может показться сложнее простого wcf, тем более, что в wcf есть возможность сделать rest-сервис, поэтому я попробую обосновать плюсы web api.
1. Универсальность из коробки. web-api работает работает через http и отдаёт данные в json. Их просто собрать и в веб-приложении, при этом любой клиент всегда может обратиться к ним просто послав http-запрос.
2. mvc web api очень легко прикрутить к фронтенду с помощью knockout.js или angular.js. Фактически, это работает "из коробки" - делаешь запрос, получаешь в js построенную модель.
3. Даже в настольном приложении через .net всегда можно легко и, главное, асинхронно работать с web api через класс HttpClient (он же есть для WP).
4. Нет .net? Это просто http-запрос, стучаться легко с других платформ.
5. Как хостить WCF-сервис? Это не так и сложно, но хочется простоты, всё просто должно работать. web api хостится так же, как обычное asp.net приложение - в iis.

В офисе была только книга Мак-Дональда, в ней много теории, есть примеры, которые сложно использовать в реальной жизни (поскольку WPF без MVVM практически нежизнеспособен), поэтому вначале она мне не понравилась, но позже, при необходимости реализации сложного UI на WPF мы часто к ней возвращались, как справочник её использовать крайне удобно.
И знание внутренних механизмов работы WPF хорошо помогает в отладке - понимаешь причину ошибок, где-то не всплывает пузырьковое событие, потому что перехватывается внутри, где-то не срабатывает биндинг, поскольку проблемы с привязкой (привязка идёт к свойству объекта, а поменялся сам контекст).

Доброго дня.
Нужно выбирать действительно необходимый вам возвращаемый тип. С IEnumerable есть некоторые тонкости, которые необходимо знать и всегда о них помнить. Очень советую обе статьи, еще немного информации о коллекциях есть здесь. Я попробую уместить в паре строк основные правила.

IEnumerable(T) нужно возвращать только в случаях, когда клиент готов принять итератор, потенциально бесконечный! Фактически, этот интерфейс не стоит использовать почти никогда.
IReadOnlyCollection(T) нужно возвращать (и передавать в методы) в случаях, когда клиент пользуется данными коллекциями, но не должен изменять их. В большинстве случаев это именно так, можно сказать, что IReadOnlyCollection используется чаще остальных.
IList(T) и ICollection(T) возвращаются в случае, когда клиенту может понадобиться изменить коллекцию, добавив или удалив элементы. Такие ситуации встречаются крайне редко. Различие в том, что в случае с IList(T) клиент может обращаться к элементу по индексу. Что касается передачи этих интерфейсов в качестве аргумента метода, то это может понадобиться, когда метод модифицирует коллекцию, например, удаляет дублирующиеся элементы или очищает коллекцию от старых данных. Здесь есть выбор между явной работой с коллекцией или же передачей IReadOnlyCollection(T) и возвращением результата того же типа. Зависит от задачи.

Я бы сказал, что IReadOnlyCollection(T) наиболее предпочтителен в качестве возвращаемого параметра, поскольку при таком подходе код остаётся структурированным - можно быть уверенным, что возвращаемая коллекция не модифицируется ниже по коду.

p.s. Ах да, напоследок. У вас приведены примеры нетипизированных коллекций, которые медленнее их generic-собратьев из-за упаковки-распаковки. Ими пользоваться стоит только в крайний случаях, пример которым я наспех даже и не приведу.