I wouldn't say a DBA needs to know how to configure any specific device, but I would say that a DBA needs to know more than old DBA tales like "RAID 10 good, RAID 5 bad".

Everyone will have different opinions, but I'd roughly start out as

OS level fragmentation, LUN vs. RAIDset vs. spindle definitions, SQLIO or other detailed benchmarking, general cache effects, reading and interpreting Perfmon and SQL performance metrics, sector and stripe sizes, partition/LUN/etc. alignment, and potential bottlenecks from drive head to output data.

Of all of this, knowing the possibilities and being able to benchmark well are the two most important; if you can benchmark many configurations, then you'll understand your own environment, and have the capability to make rational choices. Benchmarking well is difficult, especially benchmarking fragmentation effects; too many fragmentation techniques leave sequential fragments filled in non-randomly, often over a small enough area that cache effects play a large part in their results.

While a DBA doesn't (always) have to be a SAN engineer, at companies with SAN engineering, a DBA should be able to have a technical conversation with one, be able to understand the SAN configuration that's being set up/was inherited, be able to suggest the pros and cons of different configurations (dedicated vs. shared spindles at varying levels of granularity, different RAID levels for different database files), and be able to provide both best guess estimates and know how to run tests to provide reasonable evidence of whether a given performance issue has storage as a major contributing factor.

Sometimes the DBA does have to be a SAN engineer, particularly at companies which don't have a lot of experience at databases on SANs; they're a special case in many ways, depending on workload. Averages don't matter as much if an expensive enough SLA is about peak latency. I've seen setups that ended up with spindled dedicated to "databases"... but with multiple Raidsets and LUNS for a given set of spindles, and those shared out such that major production OLTP databases, and development databases that run multi-million row queries share spindles, without any attempt at alignment. As a result, while each LUN was dedicated, at at an OS level everything looked fine, when one kicks off a multi-million row query, the OLTP performance suffered (SAN and server caches weren't large enough, either).