An API and a web server with small segmented updates make this so much easier. Compare this to Apache, that has to wait to properly end existing connections before reloading, has a config file parsing overhead, and probably does not scale that well with several virtual hosts anyway. There are hardware/File System level limitations as well.
Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.
I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?
I would also say it's easier to enforce good "IaC hygiene" when the configs are managed via configuration files. They can go through a code review process, deployed via existing config management systems etc.
For most workloads it should be entirely possible to deploy a new stateless config and not need to resort to using mutable state for critical infrastructure.
If you have long-lived, stateful connections (perhaps for live streams) then I can see why re-configuring in place would be desirable, but in my experience that's pretty rare.
It's not so much "on the fly", as it is moving the long-term config storage to a different system.
But for API gateway or any kind of sidecars? Very valuable.
Infrastructure As Code (in all its forms, chef/puppet/ansible/tfe etc.) is the standard for all enterprise cloud setups these days. It makes sense to support that as a first class feature.
This is infrastructure-as-state
You have to manage automatically loading configs and keeping in sync with what you have in code, instead of deploying with a static configuration file
In this case, I think Nginx is trying to avoid the in-fighting that happens between platform teams and the various teams that they serve. Most platforms with static configuration don't make it easy to ACL the platform so that one user can't mess with another user. E.g. it would be hard to automatically prevent one user from trying to take another's domain name.
This config API could be ACL'ed so that you can update your application code, but not change it's domain name or IP. Or whatever else the platform team wants to cut off. This hopefully comes with ACLs like that, but if it doesn't you could always add it in a standard way with a reverse proxy that has ACLs. That's a lot easier to do than trying to write an nginx config parser to make sure platform users aren't tinkering with a particular setting in their config.