In LoRaWAN 1.1 (not yet supported by TTN), the Join Accept response can include a CFList, to tell the node which channels to use. Of course, that still requires a node to first find a suitable channel for the OTAA Join Request. For this, LoRaWAN 1.1 Regional Parameters defines (emphasis mine):
If using the over-the-air activation procedure, it is recommended that the end-device transmit the Join-request message alternatively on a random 125 kHz channel amongst the 64 channels defined using DR0 and a random 500 kHz channel amongst the 8 channels defined using DR4. The end-device SHALL change channel for every transmission. For rapid network acquisition in mixed channel plan environments, it is further recommended that the device follow a channel selection sequence (still random) which efficiently probes the groups of nine (8 + 1) channels which are typically implemented by smaller gateways (channel groups 0-7+64, 8-15+65, etc.).
For ABP, this states:
Personalized devices SHALL have all 72 channels enabled following a reset and shall use the channels for which the device’s default data-rate is valid.
I don’t quite understand that; when using ABP one would already lock a device to a specific provider, hence one could also choose specific channels, if a provider would only support some channels? Like TTN has made a selection already.
As an aside, LoRaWAN 1.0.1 also supports the CFList for, e.g., EU868, but does not for US902-928:
7.2.4 US902-928 JoinAccept CFList
The US902-928 LoRaWAN does not support the use of the optional CFlist appended to the JoinAccept message. If the CFlist is not empty it is ignored by the end-device.
LoRaWAN 1.0.3 supports it for US915 as well, but I think TTN does not support this.