Using a connection pool to the database is a form of optimization. Otherwise, you need a connection per user. This is not being done even in network where is was easy to do that for years (i.e. those using Kerberos auth for users, where the webserver just could forward Kerberos tickets to the database).
I'm sure it saves some time, but so far the speed-up hasn't seemed worth the risk, and I've been at it for about a decade. We use one server for few thousand corporate users a day, and everything is usually fast. When things are noticeably slow, it is usually from a page loading too much JavaScript, images, etc., that it doesn't really need. When it's the database, it's because of a poorly written query taking a few seconds. Rewriting the query resumes normal operations: split-second page loads.
So my web apps are becoming strongly concentrated in the edges: more and more business logic and control in the database; more and more user interface logic in the browser. It is mattering less and less what runs between them, be it PHP or Node. That section's job is mainly to take the data out of the database, wrap it in templates, and send it on its merry way.