The point that this thread highlights is that apps developers / administrators at both ends of the scale -- the enterprise and the shared service user -- normally have little say over the infrastructure architecture on which their application runs. In both these cases the infrastructure will be hosting 100s if not 1000s of apps, and the environment cannot be tailored to any one app. So issues like storage architecture and security architecture (e.g. UID-based enforcement of app separation) are a given as NFRs (non-functional requirements). Use of NFS with server / storage separation is still a standard implementation design pattern, when enterprises require simple-to-manage scalability on these tiers. We aren't going to change this, and neither will the O/P.
Surely PHP will achieve better penetration and the greater acceptance if it can offer more robust performance in this sort of environment?
Sure, but then you can go with something like Redis.
But, again, if you go back to the original question, this has nothing to
do with often-changing data in a couple of PHP include files:
We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving
mostly PHP over NFS (we have separate servers for static content)."
So they are serving up all their PHP over NFS for some reason.