Some additional context to what I'm referring, in this old blog post from 2015, nginx describe exactly why the dynamic configuration feature is important, and what's wrong with just reloading (draining the old process of connections).
https://www.nginx.com/blog/using-nginx-plus-to-reduce-the-fr...
For rolling deployments, it can cause repeated configuration changes exacerbating the problem, some workloads more affected from this than others of course. The nginx ingress controller makes this clear
> Every time the number of pods of services you expose via an Ingress resource changes, the Ingress Controller updates the configuration of the load balancer to reflect those changes. For NGINX, the configuration file must be changed and the configuration subsequently reloaded. For NGINX Plus, the dynamic reconfiguration is utilized, which allows NGINX Plus to be updated on-the-fly without reloading the configuration. This prevents increase of memory usage during reloads, especially with a high volume of client requests, as well as increased memory usage when load balancing applications with long-lived connections (WebSocket, applications with file uploading/downloading or streaming).
As long as Dynamic Configuration is locked behind an nginx plus-only API, these are hollow words.
This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.