That's often impractical for web applications, because:

1. You need a lot of system accounts
2. You need a lot of home directories
3. You need a lot of database connections

For number 3, you need one connection per user. Under mod_perl+Apache::DBI, those connections stay open, but that inevitably leaves a lot of connections open that aren't being used. That's a lot of wasted memory. Preferably, you have exactly one connection per database.

So this solution simply doesn't scale.

That depends on your authentication mechanism and authorisation model.

• If you have a small number of users it's a non-issue.
• If you have a larger number of users but small number of database users (aka authorisation groups) the HTTP user should not be identical with your webapp user, instead you have one apache user for each level of authorisation you want to give. You receive the HTTP authentication header, use your own method of authenticating the user, then set the HTTP user to be your database/system user. That way, you can have a different HTTP user for, say, admin, user and guest and each of these will only have access to their own database passwords.
• If you have a large number of database users you are entirely correct, my solution doesn't scale and you should do something else.