Probably I would use always imported version from Kernel.Guards. I believe calling Tuple.elem/2 would be really rare case.
I just think that such module is easiest way to solve problem with moving functions to modules like List or Map + document well why Tuple.elem/2 is able to be used in guard. Even moving 16 type-check and 17 guard-friendly functions would help a lot. Maybe it would be also helpful to group documentation for such functions (like we are doing it for modules).
I do wish guards had their own ‘name’ namespaces, just like how macro’s get compiled to :"MACRO-..." prefixed names, I wish guards had a :"GUARD-..." namespaces name, would make things like testing if in a guard or not unnecessary in function as each would have to be done via their own def/defguard. Many other things could be done on top of that…
But yeah, I do wish Guards were not in Kernel but where imported via Kernel, say from Kernel.Guards or so as well. At the very least the documentation aspect would be more clear.
However, I don’t see the point in changing it, it works well as it is, as long as it continues the follow the pattern it uses (consistency is paramount, unlike the inconsistent multi-arg for/with oddities ^.^;).