The "tunnel" exception is for AARP Phase 1 since if they undergo RFC1042 translation (first byte is over 0x600 and thus an EtherType), they are ambiguous with Phase 2 packets when translated back to Ethernet.
Ahh, yeah. I did understand this part of it and the ambiguity, but I guess the pedant in me was thinking the 0x600 rule was also introduced as part of 802.1H. I tried to skim RFC1042 but couldn't figure it out. Might be due to my lack of familiarity with Ethernet stuff. Either way, it doesn't really matter since it's broken in a lot of equipment regardless...
What I suspect is vendors taking shortcuts somewhere, assuming all traffic bound for Ethernet is going to be Ethernet II frames (since that is all that IPv4/v6 requires) and are just unconditionally cutting off the SNAP header
I definitely agree. Also, here's another link (it's the entire 802.11-2016 standard). See Annex M starting on PDF page 3469. Looks like the 802.11 standard actually includes these same translation tables for IPX and AppleTalk, so it's laid out pretty clearly for the vendors. What a shame that it's not always followed...