While DICOM is very complicated, both NRRD and NIfTI are very simple. From my perspective, they fill a very similar niche and are of similar complexity. I would choose the one that is used most in your domain.
NIfTI is very explicit, with a fixed 348-byte binary header. This makes it very simple to read. However, it is a bit harder to write, because it demands the order of image data dimensions (e.g. a Red, Green, Blue image MUST be saved RGBRGBRGB…), the first three dimensions must be spatial the fourth temporal and dimensions 5,6,7 are up to the user.
NRRD is text based, so it is human readable. It is easy to write, as you can easily describe whatever order you want to your dimensions. The trade off is that it is harder to create a reader, as you need to juggle the image dimensions. What is elegant about NRRD is that the flexibility of the header allows you to create a tiny header that describes a complicated image in a different format, for example you could write a NRRD-format nhdr file that describes most uncompressed DICOM images allowing easy support for DICOM.
With respect to speed, both are very fast to parse, and the small cost of the header is swamped for larger images. Without a doubt, NIfTI being all binary is faster, but in real world cases the amount is negligible. Further, since the NIfTI format is so constrained, many users add a BIDS JSON text sidecar to store extra information, and reading this incurs the same penalty as the text header in NRRD.
In my experience, Slicer supports both thoroughly, so you might want to look at other tools in your toolchain to decide.