It seems more likely that you'd spend more time in the framework. After all, it gets used on every single request, whereas your time-consuming app-specific code is probably only a few core pages of your site.
If your data store structure and queries (SQL or otherwise) are designed to perform and scale, you can get in and out very quickly (milliseconds or less), after which you'll spend most of your time turning the data into something useful.
(That's even before we talk about caching so you don't have to talk to the data store at all...)
Facebook didn't write HipHop (and reduce CPU utilisation by 50%) because their database queries were slow!
A bottleneck is something you get when you have multiple concurrent actions and one of them is slowing down the actions of the others. No matter how fast the other actions get, the slowest one is the bottleneck.
Framework overhead is not a bottleneck at all, it's just overhead. If your framework takes 10ms to load, it doesn't matter if your database is taking 200ms or 2ms to return it's result, you still pay the extra 10ms for the framework loading. This is because the 10ms is not concurrent with anything, you just pay it at the start regardless.
Now you can argue that the 10ms is not significant when compared to the 200ms your spending in your database, but this is an entirely different kind of argument.
Granted it may well be good for common functions required in intensive background processes.
Yes, it's true that a simple request router will probably not add a lot of overhead, whether it came from a framework or was something you rolled yourself (there's only so many ways to parse a URL). The real overhead comes from the other stuff the framework does, and chances are the heavy lifting will be in an ORM and a couple helper functions with badly written regular expressions.
Disclaimer: I haven't looked at the code for this framework, but that's pretty common among all of them.