There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files.
In other words, "Enterprise" code, which is in my experience usually designed more to hit all the "best practices", and often according to the opinion of some idiotic tool (as in computer program, although sometimes a person too...), than do anything sanely.
If the original developers have moved on, and the current developers do not have a good handle on the software, there could be some troubles making changes.
What if we approach the problem by structuring the code and choosing names to better reflect the business terminology. Make it such that a business person could understand the software at high level.
Then years later, it becomes much easier for a new set of developers work with the business side to make enhancements and changes.
It's all about keeping the scope of what you're doing in mind and using the correct tool for the job. Saying "this tool is better for every job" is going to get you a lot of arguments.
Also, with the exception of the third bullet point, you can follow all of those practices and still fit your app into a single file. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files.
And the final bullet point in regards to PHP is just false. But I digress.