Good variable names and documentation are infinitely more important than new shitty frameworks or do vs "{" vs "\t".
I always hear people say this, but I've used both a fair bit and `rails s` plus port forwarding is an order of magnitude easier than fighting with apache's vhost config.
I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).
It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.
The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached.
So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.
Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.
The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
None of these are necessary if you have properly configured your web server.
A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values:
>>> md5.md5("hello").hexdigest()
'00000000000000005039985304054aac'
>>> md5.md5("hello").hexdigest()
'00000000000000009ebb1c1ea77b5505'
But I get your point about PHP's deployment story being one of its (arguably few) strong points.
People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security.
Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems.
You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it?
The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache.
Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
What is?
For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache.
Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.