They provide limited configurability of server functionality within a webroot. That's extremely convenient for PHP webapps. For many PHP apps, deploying them on anything that is not apache means touching the server config itself.
Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.
Caching is a thing. Only dump the cache when a changed is noticed.
Its model is fundamentally flawed precisely because it was based on the fundamentally flawed PHP model (website assets and code are stored and hosted from the same webroot). This allowed for shared hosting to exist but containers and reverse proxies are a far better way of organising such sites today.
The fact that in other webservers the server's configuration is configured through its configuration file and not the content of its webroot is a feature.
Really not sure how one could possibly read my comment as me saying htaccess is the only way of configuring Apache?
Nginx uses way less memory in most use-cases (1/4 to 1/10), but with dynamic content like php it is only slightly better (maybe 15% if lucky). Also, setting up websocket proxy in Nginx is still a bit of a bodge.
Each server type has its own trade offs, and a list of known mitigations the uninitiated must learn. If you have a single domain high-traffic site with static media files, than Nginx is probably going to matter more. =3