Great find! (And I feel bad for not peeking into the actual messages, while @DefProc provided such good details!)
The 1.0.2 specifications state to stop processing:
Note: The length of a MAC command is not explicitly given and must be implicitly known by the MAC implementation. Therefore unknown MAC commands cannot be skipped and the first unknown MAC command terminates the processing of the MAC command sequence.
…and for nodes:
It is therefore advisable to order MAC commands according to the version of the LoRaWAN specification which has introduced a MAC command for the first time. This way all MAC commands up to the version of the LoRaWAN specification implemented can be processed even in the presence of MAC commands specified only in a version of the LoRaWAN specification newer than that implemented.
Indeed, some have claimed not seeing the data in TTN Console when DeviceTimeReq was used. But others say data was still displayed, though reading that claim again today raises new questions:
Still, just to be sure: there is no Decoder involved in the Payload Formats in TTN Console, right? (The successful uplinks show no sign of that.)
In short: of course @cslorabox is very likely right that this is the culprit, even though earlier reports differ. 
I’ve heard that V3 makes debugging easier…
(In an earlier version of this answer I referred to my November 2018 issue report #748, in which I thought TTN was not stopping processing. Looking at the code again, I now see that the actually parsing was already done elsewhere, not in the code I referred to. So while I might have reported the symptoms in that issue, I think I wrongly interpreted their cause.)