@lassoan often the SForm and QForm are the same. A good approach would be to use whichever has the larger NIFTI1_XFORM_CODE, and use the SForm if they are tied. In general, I would only expect these to differ if the acquired data could not reported in the QForm (e.g. CT scan with shear) or if the user coregistered the image so that the raw transform is still in the QForm and the subsequent coregistration uses the SForm. I am pretty sure recent releases of SPM and FSL attempt to set both the QForm and SForm to the same value (to the extent possible) to reduce issues with ITK based tools like ANTs. In this way, modern versions of SPM sacrifice the benefit of two representations (patient space and standard space) in order to ensure ITK compatibility.
In the interest of full disclosure, before the NIfTI format was finalized I explicitly criticized the inclusion of these two spatial mappings. The desire for backward compatibility with the Analyze format made it hard to store two matrices (as they would not fit in the header). The QForm was seen as sufficient for raw MRI and the SForm allowed 12-DoF coregistration without reslicing the data. It does mean that every tool that wants to support this format needs to support these two ways of representing space, e.g. nifti_quatern_to_mat44 / nifti_mat44_to_quatern. So not only do I feel your pain, but part of me feels that this was an issue that was vocally identified prior to the format being finalized. I feel very similar to the BIDS format, where I also raised concerns. In any democratic discussion of a format one will always feel there was a compromise. However, this niggling issue is small compared to the overall benefits for these unified formats.
I did contact the ITK team about a decade ago about adapting code to behave similar to other tools. I think there was a concern regarding unintended consequences of tools that assumed ITK volumes always have orthogonal dimensions. As I understand it, ITK can not abide by non-rectangular volumes, so while the SForm in NIfTI is particularly clumsy for ITK.
To be clear, this is an limitation with ITK not NIfTI. One could just as easily create a NRRD header where space directions defines a shear and ITK will treat the volume as rectangular. Likewise, there are many DICOM CT scans with shear.
Further, while NIfTI is complicated by having both quaternion and matrix representations, the NRRD format is complicated because it allows the user to specify the frame of reference. This makes it really easy to write a NRRD header, as you can use the same frame of reference as the source data (e.g. NIfTI LAS or DICOM RPS). However, a fully compliant NRRD reader must handle all the possible transforms. Form my perspective, NIfTI headers are trickier to write than NRRD, but they are easier to read.
As an aside, matrices tend to be very familiar to developers, as they are useful for so many problems (e.g. GLM statistics). They seem like a natural way to represent space in a manner that is intuitive. Therefore, I think I was not alone when I had an initial distaste for the alien quaternions. However, they do have some remarkable properties. They allow us to interpolate between two orientations gracefully and provide a nice way to avoid gimbal lock. In addition, the inability to store shear can actually be an asset, as it avoids rounding errors from accidentally inducing shears. Therefore, I certainly appreciate quaternions, but I maintain that including both matrices and quaternions into an otherwise simple format has had repercussions.
I do not think NIfTI is poorly specified. I think the ITK developers made an explicit decision to use the representation they could fully encode. This was a different choice than other tools. Nowadays most tools attempt to store the same value in the Q and S Form (to the fullest extent possible). Beyond this one issue, the format is remarkably simple helping developers focus on the unique processing of their tools with simple and efficient I/O routines for interchange.