In most cases, XML is overly verbose. CSV is more compact, more humanly readable, has a greater 1-to-1 correspondence to rows of data in your database, and is a more 'native format' for a spreadsheet (rows/columns of the CSV correspond to rows/columns of the spreadsheet).

XML has it's place, but IMO it's been greatly misused/abused. Say, for example, that you needed to generate a very complex report. Generating the data for the report was going to require multiple complex, multi-table joins on tables having millions of rows each (not the kind of thing you want to have to do very frequently). Let's also suppose that you want to generate your report in several formats: maybe HTML, for a web page; CSV for a spreadsheet; RTF for a MS-WORD document; and maybe PDF, just for grins and giggles. In a scenario like that, it might make sense to hit the database ONCE, store the results in XML, since it makes a good INTERMEDIATE format, and then run a series of converters in parallel (i.e., xml-to-html, xml-to-csv, xml-to-rtf, and xml-to-pdf).

Too many times I've seen people using XML as a kind of flat-file, text-based, database language. That's not what it was designed for, and it's not particularly good at it.

If you only have one target output (not many) and you can more easily generate that output (i.e., CSV), there's no need to go through the extra effort of generating XML as an intermediate format. Read the docs on cpan for Parse::CSV and compare to XML::Parser and think about if you really need to use XML or not.