Или трассировку истории операций.

Логирование? Как можно вообще разрабатывать без логирования и трассировки, особенно при MSA?  Мониторинг это тоже необходимая часть production grade productа. Simple design это про отсутствие неиспользуемого функционала "на будущее". Логирование это вообще гигиена

Смотря что под этим понимается. Если это бизнес-операции, то может быть и не нужно делать сразу. А если у вас скажем Event Sourcing, то история получается  "из коробки".

Если речь идёт о том, что «ваши метрики производительности не должны усложнять работу пользователя», то да, это и без XP вроде очевидно, это любой Lean имеет в базе. А вот «не собирать данные, если потребность в этом не обоснована», не всегда стратегически верный ход, особенно в эпоху big data.

Оставить возможность для изменений без понимания возможных изменений - не работает. Все равно есть предположения о возможных направлениях и изменениях как ФТ, так и НФТ.

Собственно, архитектору платят за их выявление. Иначе архитектор не нужен, живи себе сегодняшним днём и удивляйся сюрпризам завтрашнего.

Для этого например вводятся абстракции, которые в последствии могут быть реализованы иначе.
Минимизация upfront решений - основная задача архитектора.

Абстракции - это тоже лишний код и лишние траты ресурсов, никакой разницы.

Абстракция говорит «нужно», ЧТЗ говорит «не нужно». Кому верить?

А может само ЧТЗ не нужно?

«Всё по паттернам» — это антипаттерн

Потребность в той самой минимальной сложности откуда берём тогда?

Пользовательские истории :)

И вообще, DI для кого-то сложен, а для кого-то нет. MVC для кого-то усложнение, а для кого-то упрощение, Кому-то проще монолит, кому-то проще микросервисы. Само определение сложности требует наблюдателя.

Пользователи в своих историях напишут, что надо вкручивать точку расширяемости в сценарий оплаты через шлюз, чтобы можно было есличо переехать с Робокассы на ЯД или обратно?

Одна крупная ИТ контора заказывает у другой крупной софтверной конторы разработку не очень сложной системы, которая должна собирать разного рода события с нескольких проприетарных интерфейсов, чего-то с ними делать и выплёвывать в некоторое количество (других) проприетарных интерфейсов. Без этой системы события идут напрямую, то есть она должна встать в разрыв продуктивного трафика.
У вендора типа какая-то форма скрама, у заказчика внутренней разработки нет. Интерфейсы жёстко специфицированы, тестовую среду построить нельзя физически (но можно написать по спекам заглушки). Пустить исполнителя на продуктивные среды нельзя, потому что таковы политики заказчика.
Формируют две команды - одна на стороне заказчика генерит, описывает и приоритезирует требования, вторая на стороне исполнителя пишет, собственно, систему.

В какой-то момент исполнитель начинает выкатывать релизы каждые N недель. Утыкаются в стандартную процедуру заказчика "окей, вы только что отдемили нечто, давайте его ставить в продуктив. Для этого нам потребуется согласовать работы за месяц, имея на руках подробную инструкцию по установке. Установка будет выполняться силами специалистов третьей компании. Все необходимые артефакты положите вот на этот вот компакт-диск и передайте заказным письмом. Время установки строго ограничено. Если хоть что-то пойдёт не так, производится откат релиза, следующая возможность попробовать - через месяц после повторного согласования, если конечно в следующем месяце не будет заморозки. Если в продуктиве обнаруживается бага, производится откат релиза итд".

И тут компания-исполнитель начинает заказчику рассказывать про CI \ CD, процессы автоматической выкладки и тестирования и прочее. Были ли они поняты? Нет. Существует ли способ подружить два настолько разных процесса? Не знаю, правда не знаю.

Ну, это да. Но в конкретных фреймворках agile нет архитектуров

agile в крупном проекте это конь в парижской палате мер и весов, ростом 1 метр и весом 1 кг.
Архитекторы есть и выполняют роль координатора команд

Угу. Но это про agile в смысле манифеста, а не XP практик, которые уже не очень работают.

Конечно нет. Достаточно ввести абстракцию платежного шлюза, которая будет иметь единственную реализацию.