Опечатки:
"вместо этого, вот так: [0-9]{3}.[0-9]{4}"
В оригинале  [0-9]{3}.*[0-9]{4}
"Swift должен парсиьб строку"

Исправьте пожалуйста.

"Без такого адаптера "Вид" в VIP будет все знать о бизнес-логике".

Не всё. Вид является источником команд для интерактора. Он осуществляет управляющие воздействия на интерактор, ничего не зная о том, как интерактор будет реагировать на управляющие воздействия.

Просто, похоже, что VIP – это не "чистая архитектура" от дяди Боба.

Сама концепция чистой архитектуры от Мартина, помимо чистых компонент, подразумевает неизбежное присутствие и грязных. В архитектурном шаблоне SVIP чистым является интерактор. Именно на изоляцию бизнес-логики в интеракторе, и его тестируемость (и только его) были направлены усилия при создании шаблона SVIP. Презентер и вид не являются чистыми компонентами. Обоснование этого решения развернуто изложено в статье.

Вы не считаете это ошибкой реализации VIP относительно описанных у дяди Боба колец с адаптерами?

Не считаю. Само наличие концентрических колец в схеме Мартина указывает с одной стороны направление зависимостей, а с другой на ослабление чистоты уровней от центра вовне.

У Мартина контроллер приведен для примера как сущность за пределами вариантов использования. Не следует связывать контроллер с картинки Мартина с какой-то конкретной сущностью в iOS. С точки зрения Мартина контроллер это то что формирует запросы в интерактор. То есть, у нас это Вид.

А причем тут "чистая функция"? Мы тут вроде бы о "чистой архитектуре" рассуждаем, которая вообще никак к с чистой функцией не пересекается. Это вообще разные понятия.

Например в чистой архитектуре нельзя просто так взять и подгрузить данные по мере выполнения бизнес-логики. Сущность ничего не должна знать о БД. 

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

Кажется, SL имеет право на существование. Но применение его лучше ограничить. В моей практике (на iOS), архитектурный модуль разбивается на две части: Чистую и Грязную (термины Роберта Мартина). Чистая содержит всю логику и обладает свойствами чистой архитетуры (SOLID). Грязная часть занимается конфигурированием чистой (называется <Module>Configurator>) и передачей управления в другой модуль (называется <Module>Router). Вот в конфигуратор и роутер вполне уместно передавать SL. Конфигуратор применя стратегию Pull вытягивает все внешние зависимости и применяя стратегию Push собирает (конфигурирует) архитектурный модуль. Таким образом, вся информация о внешних зависимостях модуля локализуется в конфигураторе. А SL из роутера одного модуля передаётся в конфигуратор другого (который SL передаёт в свой роутер и т.д)

Спасибо за перевод
Вместо animator.isReversed = !animator.isReversed можно писать animator.isReversed.toggle

Set прекрасен, но требует чтобы добавляемые в него элементы были Hashable. К сожалению, функции, замыкания и методы классов нельзя хэшировать. Что делает его непригодным для применения в нашем случае.

KVO да, но им пользоваться крайне неудобно и к тому же вы ограничены только objc классами. И не ко всем свойствам применимо KVO, а только к KVO compliant. Property Wrappers и Property Observers имеют весьма отдалённое отношение к обсуждаемой теме.

Статья на которую вы ссылаетесь описывает возможности функций в Swift. B качестве иллюстрации там приведён полуфункциональный пример add(target:, action). Без возможности удаления слушателей как в UIControl и без поддержки responder chain. Да ещё с избыточной заумью.
В статье target.map(action)?(view) можно заменить на target?.action(view). Всем моим критериям пример из статьи не удовлетворяет. (Например нет возможности удаления слушателей - а если добавить она будет неэффективной). В моей статье есть краткое сравнение с UIControl и NotificationCenter. Кажется, этого достаточно. Моя статья не имела целью раскрывать возможности функций в языке Swift. Этому посвящено множество других метриалов, в том числе тот на который вы ссылаетесь.

Непонятна ваша настойчивость. Observer - универсальный шаблон проектирования. Из набора GOF. Если Responder Chain (тоже из GOF) прекрасно работала и без моего Observer, зачем пытаться натягивать Сову на Глобус Observer на ResponderChain?
Уже писал: подумайте об Observer когда вам нужен NotificationCenter или что-то похожее.

Совершенно необоснованный вывод о заточке под "конкретно работу с responder chain" - в UIControl вполне успешно работает классический подход. Представленное решение скорее децентрализованная альтернатива для NotificationCenter. У NC - есть ещё один минус. Либо использовать @obj-c методы либо обязательная ручная отписка. Основной же прицел был представить качественную альтернативу самописным MulticastDelegate. Я несколько раз с ними встречался в различных проектах и каждый раз это было унылым г-кодом.

Вероятно у вас даже получилось бы примерно то же самое, но с массивной и сравнительно медленной (backpressure management) инфраструктурой и внешней зависимостью от Combine. Если вам нужна backpressure, пожалуйста - пользуйтесь Combine.