Text::CSV uses Text::CSV_XS if it is available for the platform. It seems to me that using CSV_XS directly means the code won't work on a platform without XS capabilities whereas it would have worked if Text::CSV had been used. From reading the pod I don't see any advantage to using Text::CSV_XS directly. Have I missed something?
Probably not. I think it's just a problem of the timeline, or an old habit.
According to CPAN, Text::CSV 0.01 was released on 1997-Jul-31, followed by 1.00 on 2007-Nov-27, more than 10 years later. Text::CSV_XS 0.16 was released 1999-Feb-11, followed by several releases up to 0.23 released 2001-Oct-09. During that time, Text::CSV did not change at all. In 2007, both Text::CSV and Text::CSV_XS saw a maintainer change and have been updated since then. During that maintainer change, Text::CSV was "rewritten to make a wrapper to Text::CSV_XS and Text::CSV_PP".
I learned about Text::CSV_XS between 2001 and 2007. During that time, Text::CSV seemed to be an unmaintained and incompatible "first shot" version, and most other modules of that time, including DBD::CSV, used Text::CSV_XS. DBD::CSV still depends on Text::CSV_XS.
Installing Text::CSV should be sufficient, and works without requiring a compiler, but it is slower than the XS version. The Makefile.PL from Text::CSV hints that installing a sufficiently recent XS version makes Text::CSV faster, but it does not attempt to install the XS version, even if a C compiler is available.
Text::CSV_XS, on the other hand, does not depend on Text::CSV, and does not require it to be installed. It requires a working C compiler, but then, it is faster than Text::CSV.
It would be nice if Text::CSV would attempt to install the XS module if that is possible. This way, there would be no need to install Text::CSV_XS manually.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)