@sam_uk
Correct, a LoRaWAN Node transmits and can be picked up by any LoRaWAN Gateway in range, its what happens next...
So, I'm inferring a bit rather than knowledge based on trying things out (always dangerous). I'm assuming (ahem) that each device and application needs a unique ID in order that it can identify itself on TTN, otherwise how would you know that data from Sensor A was destined for Application A? Also, these need to be globally unique identifiers across the whole of TTN, and that requires an ID scheme or centralised conflict resolution through some form of initial one-time global registration. Let's say that Sensor A is mobile and moves from one LoRaWAN country's infrastructure to another. All the routing of encrypted data traffic still has to work correctly and not get mis-directed to the wrong end-point (or handler as I think its referred to in the future system design), which could happen if Sensor/Application IDs are not uniquely assigned across the whole system...
The alternate which I haven't seen mentioned in relation to the architecture, is that TTN essentially creates a central pool of all received encrypted messages from sensors, and applications simply search/filter this pool for encrypted messages for which they hold the decryption key. TTN could purge messages from the pool after a certain period of time. TTN wouldn't then need to be so bothered about explicit routing or GUIDs...
However, I do have some concerns about the possibility of fake/impersonated Node traffic being generated in TTN, but the TTN software stack is very much under development so its difficult to assess whether there may be any issue in this regard...