Interesting topic.  However, one aspect that hasn't been mentioned is how this will impact the object oriented design of your applications.  If you consider that the clients in this case are a set of application servers and the server is the DBMS server, then it seems as though you'd need to often trade off good, partitioned, object oriented design in order to reduce the number of DBMS server calls.  For example, if you have a Person object with persisted data in the database and a Company that's also persisted in the same database, you'd want those objects to be in control of the structure of the underlying data.  With this in mind, you'd also want those objects in control of the SQL commands that are used to instantiate/manipulate them.  Granted, I could see providing some sort of control layer between the business objects and their underlying data such that you could do most of your instantiation (queries) all in one shot, but it seems that this would significantly complicate the design.  Also, there are going to be other adhoc data needs that the business object will have during the course of use.  I'm not sure it's practical/desirable in many cases to "funnel" those data requests through a single shot to the server.  Lastly, making the individual connections should not be a concern -- connection pooling should help to reduce the overhead associated with this. 

While performance is important, it usually isn't good to gain performance while compromising/complicating your software designs.  As I've heard mentioned in the recent past, hardware is cheap compared to the cost of human-power required to maintain a poorly designed system.