> Что он делает?

NGINX Unit - это такой сервер приложений.

Сервер приложений - это программа, которая управляет рабочими процессами других приложений с целью их публикации и доставки до пользователей.

Вот допустим у вас есть приложение (в подавляющем большинстве случаев это веб-приложение), которое принимает запросы по сети и шлёт в ответ какой-то динамический контент (HTML, XML, JSON, итд). Само приложение написано на каком-то языке программирования. Вопрос: вы как его будете публиковать?

Сам по себе веб-сервер nginx, каким бы он не был быстрым, уступает полноценным серверам приложений вроде Apache и IIS в том, что он просто веб-сервер и прокси, но не сервер приложений. Если вы когда-нибудь поднимали сайтик хотя бы на localhost, вы знаете, что nginx не управляет вашим приложением, он прицепляется к php-fpm или к другому серверу приложений, реализующему интерфейс FastCGI. За FastCGI API находится демон, который порождает рабочие процессы интерпретатора. Каждый рабочий процесс - это процесс в операционной системе, куда перенаправляются запросы клиента.
HTTP (web server) <-FastCGI API-> Application Daemon (worker1, worker2, worker3)

В зависимости от языка приложения Application Daemon для nginx может быть разным, но то что важно понимать: nginx понятия не имеет о том как работает приложение, не контролирует ресурсы ОС, многопроцессность, многопоточность. Nginx не понимает, какой pipeline обработки запросов внутри приложения. Nginx не может создать новые экземпляры рабочих процессов. Не понимает, что он может быть частью кластеризированного приложения.

Всё что я написал выше умееют другие сервера приложений.
- Apache полностью контролирует свои модули Apache portable runtime (APR)
- IIS контролирует не только ISAPI-модули, но также .NET, и некоторые другие (вроде nodejs), которые либо просто поддерживаются через сторонние модули, либо из коробки.
Кроме того, есть Java EE, она же Jakarta EE, которая стандартизирует сервера приложений Java сервелеты и прочее. Apache Tomcat, Red Hat JBoss (Wildfly) их много. Ruby on Rails, опять же... ей нужен сервер приложений Passenger

Именно сервера приложений бывают нужны для крупных проектов в ентерпрайзе. Вы можете поставить Apache HTTPD или IIS и никогда не пользоваться этими функциями, просто потому что не видели крупного приложения. Или возможно, вы поставили приложение которое притянуло готовый Tomcat/JBoss, но сами сервлеты вы не писали и не публиковали.

В общем, NGINX Unit - это ответ от NGINX, потому что основной сервер nginx на самом деле глуп и не умеет ничего такого.

Вот только есть пара проблемок:
Разработчики NGINX Unit люди странные, не понятно кто им ставит задачи.
Например, в их сервере приложений, который живёт отдельно от nginx и использоваться вне корпоративной среды не будет, нету:
- Поддержки ASP.NET Core, хотя, казалось бы, в нее встроен Kestrel и не обязательно заниматься реализовывать In-Process Pipelineб как это было во времена .NET Framework.
- Нет поддержки HTTP/2. Вы спросите почему? А вот идите нафиг, вот почему. Вы хотели использовать gRPC в своих приложениях? Хотели пользоваться бинарным дуплексным обменом данными с другим приложением? А вот нефиг! Лучшее что мы можем предложить - это SOAP поверх HTTP/1.1
- Нет поддержки современного серверного железа.
Это вообще всеобщая беда, которая делает IIS незаменимым в ентерпрайзе. Многопроцессорные конфигурации или однопроцессорные Xeon Scalable с несколькими узлами NUMA не поддерживаются не только в NGINX Unit, но и в самом nginx и тем более в Apache HTTPD.

> Я так до сих пор и не понял смысл этого NGINX Unit'а. Зачем он нужен?

Вот на этот вопрос и я бы хотел получить ответ от самих разработчиков без всякой иронии. В чем сакральный смысл запихивать КЛИЕНТСКИЙ код на WebAssembly внутрь сервера, типа в стиле бинарный формат же есть, значит мы можем исполнять...
Они понимают, что WebAssembly - это байткод который придуман специально для интерпретации MV*-фронтенда в браузере без требования к JavaScript?..
При этом у них ни gRPC, ни .NET, ни HTTP/2, ни железа. Там люди думают, как ProtoBuf засунуть в QUIC и стандартизировать формат метаданных (Netflix придумывает новый формат дуплексных RPC), а они фигней какой-то занимаются.