The files in question do exist on the N3DS, but were not part of the 9.0/9.2 SOAP replies for updates because the last time they were updated was around 7.x and 8.x, and the very first run of N3DS systems shipped with 8.1 (in Japan only but that is where the "initial version" sits for the N3DS) and its very first update was 9.0. Since those titles were not updated again after 8.0 until 9.6/9.7, they did not bother adding them to the update packages for the N3DS until then in order to save bandwidth. Why send files for a hardware that cannot possibly need to update them?
The files in question with unexpected versions (0004013000001a02, 0004013000001b02, 0004009b00010402, and 0004009b00010802) are all universal between O3DS and N3DS. For future reference, ALL titles that are N3DS only have a "2" as the 9th character in the TitleID. If a title is installed on the N3DS and has a "0" for that character then it does not have a N3DS unique version or it would have been installed instead.
I am pretty sure GPIO handles HID input (likely specifically the lower/touch screen) and I know DSP is the sound module. Since neither of these components were "ugpraded" in the N3DS it makes sense they would not have unique titles. I would strongly recommend you download them though to avoid potential weird errors since one handles I/O memory calls and the other handles sound (thus both are central to a stable experience).
As for the other two, according to 3dbrew, the *10402 title is a container for a list of "area"s (country and province/state names) so it is probably not likely to cause major problems if left alone (especially since once you update your emunand back to 10.5 it will get changed again, and I highly doubt area/country names will have any impact on the success/failure of hacks). The second title (*10802) contains a single file called "dummy.txt" that in the updated version contains the string "1", and the string "0" in the version expected to be installed on 9.2. Again this one can probably be left alone, but the fact that it DID get changed implies that something in the system references it and I am unsure what service or program that is. Thus it is entirely possible that something central to a successful execution of the arm11/arm9 exploits references or calls it and it might result in a higher failure rate if left alone. Thus, for the sake of completeness, I would replace BOTH titles with the proper versions.
While you are correct that once updated back to 10.5 your emunand would have the updated files anyways, but I would still downgrade at LEAST the GPIO and DSP file. While DSP might not have any impact on the successful booting of the hbl or cfw, issues with I/O could most definitely cause problems.