Антон Швец

1) правда ли изучаешь один раз и применяешь везде?

да.
У нас не принято собирать разнообразные велосипеды из набора либ. Разве что стейты vs сервисы :)
Меня всегда это вымораживало в реакте, чтобы реализовать привычные вещи приходится тащить черти что и еще выбирать самому. А чтобы выбирать нужно уже знать варианты.

2) как обстоят дела в крупных проектах?

По разному, но в целом они похожи все. Если разработчики достаточно опытны в ангуляре и ООП, чтобы писать нормально.

Архитектура приложений будет больше зависеть не от Ангуляра, а от знакомства разрабов с принципами построения архитектур, которые в целом несложны.
Сам Ангуляр ничего не навязывает, Nuxt в этом плане даже более структурирован. Однако и так все само получается примерно схоже. Отчасти поэтому nuxt/next для ангуляра не существует.
Еще популярен Nx, который помогает собрать монорепу из angular+nestjs например.

стоит ли?

Определенно стоит ознакомиться. Некоторые практики, без которых Ангуляр сложно представить, можно использовать и в react. Например di, если еще не используете.

шаг 1. Делаешь сервис где хранишь данные

private data = new BehaviorSubject(null);

  setData(data) { this.data.next(data) }
  selectData() { return this.data.asObsevable() }

Понятно да, как с этим обращаться?

шаг 2. Выводишь данные в компоненте
data = this.myService.selectData()

<p> {{ data | async }} <p>

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

нет никакого стека MEAN. Это просто свободно заменяемый набор инструментов, причем монгу вообще нет смысла брать. И родилась эта аббревиатура еще во времена первого ангуляра и вырвиглазной ноды, еще до nest.js и тайпскрипта.
Все мануалы того периода сейчас уже нельзя воспринимать всерьез.

1) useExisting не создаёт новый экземпляр зависимости, а создаёт ссылку на него под другим классом, служащим ему заменой (алиасом).

не ссылку и не под другим классом.
Когда провайдишь сущность, ты сообщаешь di-контейнеру (у нас это инжектор) di-токен, по которому инжектор выдает тебе сущности.
Класс для него это частный случай di-токена.
Можно ведь и так сделать

providers: [{
  provide: 'doc',
  useExisting: DOCUMENT
}]

Подробнее тут https://angular.io/guide/dependency-injection-prov...

2) useExisting следует использовать вместе с useClass

Опять же, не обязательно класс, главное чтобы сущность связанная с токеном в useExisting была уже известна инжектору.

3) класс-алиас, который внедряем должен полностью соответствовать интерфейсу оригинального класса на который мы собираемся заменить.

Не обязательно, инжектор твои типы не проверяет, просто выдает то что он запомнил.

А по главному вопросу

Когда следует использовать UseExistingProvider?

Когда тебе нужно существующую сущность предоставить под другим токеном. Допустим какие-то другие классы инжектят себе зависимости по им известному токену, вот, чтобы они по нему нашли наш инстанс.
В ангуляре полно такого, HttpClient инжектит HTTP_INTERCEPTORS, директивы форм инжектят NG_VALIDATORS, бутстрап инжектит APP_INITIALIZER и т.д.

Вместе с именно классами useExisting практически не используется, не вижу смысла.

да
для браузера и поисковиков это обычные кастомные элементы, они нейтральны.
Для семантики можно role прописывать.

this.http.post(url, {
  login, password
})

ниче не надо больше.
Подписываешься, реквест отправляется, json в body будет автоматом.

Observable - наблюдаемый объект. Наблюдаемый.
Его потребитель всегда может знать когда произошли изменения, запустить обновление вьюшки, плюс выстроить свои потоковые цепочки из операторов.
А если ты просто что-то в сервисе там изменил, ангуляр скорее всего об этом не узнает. То что у тебя работает, значит что где-то в это время сработала проверка изменений (скорее всего глобальная), т.е. просто повезло.

по дефолту запрос возвращает json.
Впишите observe: "response" в опциях запроса. Третий аргумент