Many, many good reasons to use DBI over that.

Firstly, think of all the escaping necessary in defining $cmd. You need to think about not just escaping string literals at the SQL level, but also shell escaping because the command will be passed to your shell, and lastly Perl literal escaping. Ouch.

With DBI you eliminate the need to think about shell escaping; and if you use prepared queries in DBI (which you should) you also eliminate the need to think about the escaping of SQL string literals.

Secondly, accessing a database via pipes means the data you get back needs to be parsed. This can be non-trivial, especially if some of the results will include multi-line strings.

Thirdly, using DBI, if you avoid using vendor-specific SQL extensions, it's pretty easy to write code that will run on many different databases - even databases you've never heard of. You'd never get that parsing the output of command-line SQL clients because each client has its own output formatting, its own command-line argument parsing, etc.

q.v. bobby-tables.com