DBIC is shorthand for DBIx::Class not DBIx. DBIx is, in fact, nothing but a prefix. There is no DBIx module. There are several hundred DBI based packages that use the DBIx prefix and many differ completely in purpose and usage.

DBIC does not simply abstract 1:1 with tables. ResultSets and Result classes cover a lot including plain highly reusable SQL like SQL::Abstract, without necessarily mapping to an existing table at all. And in DBIC there are column objects, storage object, schema objects, and more. Chained ResultSets is one of the most powerful and liberating ideas in DB code.

DBIC is more complicated than a plain SQL library but if written with the same kind of discipline it takes to keep an SQL library from turning into spaghetti it is self-documenting, highly extensible, repurposable, self-deploying, versionable, etc, etc, etc. Many, every one I’ve seen, home grown SQL libraries take on some of the characteristics of a good ORM, except they tend to do it atrociously without testing or sanity. NIH is a the prime cause recalcitrance in some applications.

Please provide literal examples instead of philosophy if you're going to make this kind of argument. Several of us have provided good, clean examples of DBIC on the site before. If you have a better approach, everyone would love to see a CUFP post on it.