lol, no. It meant that there was more of a layer between the web server and the DB server than just a php page with the DB credentials in it chmodded to 700.
Assume an attacker has taken over your web server with an exploit and now has full admin access to it. If there is no direct connectivity to the DB, all he can do to get at your DB is call the methods on the middle-tier services that the web server called. These are not "download all passwords" but small and tightly targetted services that only provide a smallpiece of the puzzle that ends up providing the end-user experience.
So, in practice there is nothing the attacker can do to really break your DB. He can attempt to hack the application server, and that is a fair point, but he still has to break it and if you're really doing security the app tier is running a different OS that the web tier, and is firewalled down so only specific ports can be accessed anyway and there are no similar services running on it (such as apache or IIS) that are the usual attack vectors. You also have more leeway in rejecting requests from the webserver that you do not have on the web side of things - whereas a webserver has to respond to anything the user sends to it, you can trust your webserver to only send you specific requests - and if your webserver sends you a mangled request you can rightly assume its been compromised and start to refuse all requests from it (this works best if you have multiple web servers). you raise a big alarm to the admin who can then investigate. Webserver hacks can often go un-noticed if the attacker is careful.
Assume the attacker is really skilled and has hacked your web server *and* your application server... he *still* cannot download all the passwords as they are store in tables that the app tier cannot read, all it can do is fire stored procedure requests at the DB which will only respond with what they were designed for. (none of which allow 'download all passwords')
So you see that while its not impossible to be secure in such an architecture, its damn right difficult for an attacker to really get at your precious data, So difficult they'll either be unable to do it (eg most kiddies with their downloaded apache or IIS hack cookbooks) or will find it so difficult they'll get caught, or they'll just move on to another target.
We used to have a linux web tiier, and a windows middle tier. We encrypted the DB credentials in a web.config and ran the services, each on a different user. The DB sprocs also were allowed access to only those services that required it. I would never encrypt the web tier access to the DB, because I would never allow it. An attacker could take that credential file offline and hack it at his leisure. Its best if he is not given the chance to read it at all. But worse, if he can logon as that user then he can access the DB without even knowing the password. Storing it on the easily-hacked box is the flaw here. Make it hard for them, and assume your webserver is already hacked when you code your site.
As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access. ensure they work in pairs perhaps and maybe (and this is radical for a lot of companies), treat them well so they don't become disgruntled!