As for your point on encryption, the DBAs are correct, encrypting every field in the DB will cause a performance hit, relative to the size of the database and the size of the encrypted values. Normally, only sensitive fields would be encrypted or hashed; password fields, important numbers (social security/id number, credit card number, etc.)

As for weather the data should be encrypted when being sent over the network, that really has nothing whatsoever to do with databases; I know what your thinking, but really...the sniffer who is leaching sensitive data from your network couldn't give a crap if it comes from a database, a web server preprocessor, or your email applications. Data is data, and if it shouldn't be sent in the plain, then don't send it in the plain.

One of the key points I try to convey to students and coworkers is 'security is a method, a process, a state of mind.' It is irrelevant if your application is coded in the most ultrasecure language and method available...if it is on an unsecure host, or uses unsecure methods to transmit data, it's worthless. You have to evaluate your risk at all points of exposure, decide what is acceptable, and use that to guide your planning/deployment.

Does any of that make sense? (/me has had a shitty day dealing with PHB's and CL-users)