I believe this is basically the same code that has been in itkGDCMSeriesFileNames from the very early days, which Slicer does use. As @thewtex says, this code requires that all the files be in one directory and that the directory contain only one series. This simply does not match the way many people have their data. Very often multiple series are in the same directory. And also very often (such as a DICOM exported CD or DVD) the files that make up a series are spread out across subdirectories.
The DICOMScalarVolumePlugin (and others) use the database and heuristics to create loadable chunks that correspond to the data that Slicer will be able to digest and then gives the user options about which are passed to ITK for loading.
It is worthwhile to try improving ITK’s implementation to relax some of the constraints and handle more scenarios, but it’s fairly big job and several previous efforts haven’t worked out too well, which is why there is still the legacy GDCM reader path in parallel with the newer but differently incomplete DCMTK path in ITK and exposed in Slicer.
If you look at the /vtkITKArchetype* classes in Slicer you’ll see that a lot of the code involves instantiating the ITK readers across all the range of possible image types that might be discovered from parsing a dicom series, but even this (very large) set doesn’t handle all the other cases that one might want to load from a dicom study (like SEG, PM, or various types of timeseries images).
One more point: the whole code base could obviously benefit from a fresh start, but as has been noted many times in the past, we don’t have any way to really test a new implementation. The existing implementation was developed to read data that we don’t have access to (and we never will have because much of it private patient data or was otherwise not public).