А что в этом удивительного?

IIS - это единственный веб-сервер, который пригоден для высоконагруженных приложений, работающих на железе без виртуализации. IIS поддерживает современные многопроцессорные сервера и синтетические ускорения предоставляемые в современных сетевых адаптерах.
- Обработка TLS у него в ядре и всегда была в ядре. Есть сетевые адаптеры, которые могут сделать offload и убрать криптогорафию с центральных процессоров.
- Обработка HTTP у него в ядре, причем с версии 6 (2003/XP).
- Встроенная поддержка HTTP/2 начиная с версии 10 (2016)
- Встроенная поддержка HTTP/3 в последней стабильной версии (2022)

В отличии от привычных вам веб-серверов IIS - это полноценная реализация UNIX Internet Daemon. Только в отличии от привычных для Linux реализаций, его супер-сервер работает в ядре ОС и большая часть привычных обработчиков обрабатывается там же. То есть вместо того чтобы пихать поддержку транспорта QUIC в OpenSSL, потому что толком некуда из-за требований к TLS 1.3 для HTTP/3, она в ядре и связана с сетевым стеком. Кроме того он интегрирован с сервисной моделью и не дёргает процесс с диска на каждый запрос, а перенаправляет их либо в свой воркер (экземпляр службы публикации), либо в другую службу по TCP (но это значит что это служба использует WCF).

Вот представьте себе ситуацию:
У вас есть двухпроцессорный сервер с двумя сетевыми адаптерами, каждый из которых подключен по PCI Express к своему процессору. Далее настроен бондинг так, чтобы количество аппаратных Rx-очередей каждого адаптера у вас "суммировалось". Например, скажем ASIC сетевого адаптера поддерживает 16 аппаратных очередей, значит он может слать одновременно на 16 разных ядер разделив входязий поток. Бондинг должен быть настроен так, чтобы оба адаптера задействовали по 16 ядер с каждого процессора. Далее с учётом требований по скорости обработки у вас либо есть LRO/LSO (жонглирование с MTU, когда адаптер принимает TCP и QUIC пакеты с MTU 1500, а отправляет на CPU в ядро с MTU 64K, меняя MSS в рамках одного потока и потом производит обратную операцию при отправке), тогда у вас выше пропускная способность сети, меньше переключаются контексты исполнения, либо это выключено, тогда у вас ниже задержки в потоке, но нагрузка на CPU выше.
После того как TCP и QUIC в ядре ОС у вас это приняли это передаётся в модули ядра TLS и HTTP, которые дальше производят балансировку нагрузки по рабочим процессам в пространстве пользователя с учетом того, какие воркере на какой NUMA-ноде запущены и откуда шел трафик изначально.

Естественно при таком сложном тюнинге производительности мы предполагаем, что у вас есть 4 уровня балансировки и правильно настроена сеть:
1. DNS Round Robin между регионами/локациями указывают на L4-баласнировщики/файрволы
2. L4-баласнировщики в режиме Direct Return указывают на фермы L7-балансировщиков
3. У вас настроена балансировка потоков трафика по ECMP и для внутреннего роустинга применятся BGP
4. L7-балансировщиков... ну это просто ваша HAproxy или сабж из новости, но тогда у вас однопроцессорный сервер.
И вот потом у вас IIS-ы.

Просто когда nginx научится нормально работать на современных многопроцессорных серверах... хотя опять же зачем ему...
Ну то есть он же не apache с его модулями и пайплайнами для приложений. То есть в общем случае nginx это мордочка, которая стоит перед FastCGI, либо это реверс-прокси (см п.4). Для первого он подходит (обслуживание PHP и Python через FastCGI), опять же, если у вас виртуалка, или однопроцессорный сервер. Для реверс-прокси он всегда уступает HAproxy.
Или когда nginx научится работать с чем-то кроме FastCGI и научится быть сервером приложений как IIS, хотя это вынесли/задумали в nginx Unit, но и он с железом работает от слова "никак".

И да у IIS есть традиционные Legacy-применения, типа перепубликовать WCF-службу как вебсервис, всякие старый софт, которым нужен .NET Framework, а не современный .NET. Или если есть интранетное приложение, которое оформлено как ISAPI-плагин на C/C++, а не как CGI. В остальном, если кому-то нужен IIS, то это значит, что кто-то хочет работать на железе с высокой производительностью и отказывается дарить инфраструктуре виртуализации 10-25% производительности, просто чтобы исправить отсутствие поддержки NUMA в софте.

Он в принципе всем хорош, но у него есть 2 проблемы:
1. CI/CD приложений... всё это можно, но придётся поморочиться, особенно когда оно кластерное.
2. Цена, он получается очень дорогой.

Просто смотрите, тем кто пишет микросервисы производительность приложений не нужна. Им нужна масштабируемость. Им нужно арендовать 100500 виртуалок в облаке, поставить в эти виртуалки кубернетис, туда понапихать свои микросервисы и пользоваться этим так, чтобы кубик попинывал их барахло, когда сервисы падают. Хотя и тут тоже не понятно зачем nginx...