This data set is not a single 3D acquisition and the spacing is neither 0.5 nor 0.6. The data is acquired as 52 images, within each image the spacing is 0.6mm, but between the images the spacing is only 0.5mm. If you assume overall uniform spacing then the spacing is about 0.58mm. If the slice position fields in the DICOM header are correct then the image has varying slice spacing.
It is suspicious that maybe some inaccurate post-processing was applied on the data, because the slice positions along the third axis were specified with very low precision - just 1 digit after the decimal point - while 9 digits were used for positions along the first two axes.
Overall, Slicer handled these issues well, generally staying on the safe side (not silently ignoring inaccuracies or changing the data without asking). I agree that the user experience was not ideal, because you had to enable advanced mode and change some settings - but it was all due to trying to load the data set as a single uniformly-spaced 3D volume, while the data set is actually something else.
We introduced the DICOM Patcher module to allow fixing commonly occurring issues before a data set is imported into Slicer. If you often come across data sets that are messed up like this then we could add a new rule that could force the same acquisition number to all instances in the same series. Also, if you get confirmation from the authors of the data set or from the scanner manufacturer that the spacing was actually uniform (0.5, 0.6, or 0.58) and it was just not correctly written into the DICOM file, then you could add a rule for correcting the slice position values automatically.
If you want to automatically harden the acquisition transform on the volume after import then you can enable that in menu: Edit / Application settings / DICOM / Acquisition geometry regularization → Harden regularization transform.