"More with less" here is a judgement call. You've increased the number of processes and subsystems that need to be managed (nginx + php_fpm), which is more. You've increased the context switching when dynamic requests need to be passed to another process and proxied through nginx. The communication between the frontend web server and php_fpm needs to be serialized in some fashion, so you're now incurring a greater than 1x cost in processing and parsing things like HTTP headers and the request (serializing and deserializing the data to pass that between the processes). It seems you're ignoring the actual cost of running dynamic PHP code because the cost has been moved out of the "web server", the thing that listens on port 80, and into something that isn't considered "a web server", but this is just a change in bookkeeping.

Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence.

It's great that you found something that works better for your workload, and it's appropriate to use what works and not get bogged down in why all the time. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap.