First about the advantages :

The only advantages of this approach (IMHO) are:
Security - malicious code has to navigate an extra layer of obscurity

Ahem... Security through obscurity isn't security...


Safe development - Once the abstraction layer is written,
developers working on higher levels are limited in the damage they can do
(can't "DROP TABLE")

You can achieve the same result without the SQL abstraction layer...
All you need is to provide a restricted API ( in your case the DB function layer)


Now about the disadvantages :

I'd just like to point out that the the Database locked to code problem
isn't bound to the architecture IMHO.
I suppose that even with this architecture
a clean coding could produce a relative database independance
(using list/hash to manage columns...)

Now to answer why, I have several guesses :

• Lack of impatience (too much abstraction here, to my mind)
• Some people think that complex means smart...
• The bad implementation syndrom :
  Or "how a good idea (database independance) could lead to an absurd implementation"
  By duplicating existing mechanisms(database independant API), and allowing some limitations that ruin the whole benefit(the column dependance problem))
  
• Megalomaniac Lead Programmer:
  You know the one who uses a lot of buzz words (and a lot of accronyms : DFL/SAL for DB functions layer and SQL abstraction layer ;-)

"Only Bad Coders Badly Code In Perl" (OBC2IP)