The http server's job is to translate URLs into http requests for consumption by the application. The http server should generally be agnostic regarding the semantic meaning of your URLs, which take the form of business rules, the proper place for which is the application layer (whenever possible).
At a guess because you don't use apache, you don't have .htaccess / conf permissions, you are going to distribute your script and can't rely on the above, your router uses database or other external sources, you want to be like the cool kids, or because you want to, it works, and why not?
Let's say you are using Apache (so maybe that already means you're not one of the cool kids?), then why would you use any of the available PHP routers?
Overall, I'm not trying to discount anyone's work with developing PHP routers, but I'd like to understand the benefits of using them.
It would help decouple your application code and structure from Apache configuration and the need to be familiar with Apache configuration syntax and nuance. Your Apache config would just need to route all requests to your app root to one routing file, which is pretty simple, and then the routing file can process from there. You'd also have the benefits of more configurable routing, if you needed that (e.g. routing based on specific parameters in a POST instead of just based on the request url and method).
Do you have experience with massive http conf files? They become very hard to maintain! There is always going to be tradeoffs between maintainability, speed and ease of use. It just depends what sort of application you are running.
