Simple overview of what SF’s (and thereby DR’s) are supported by the silicon: Original Conc baseband chipsets - SX1301 & 1308 derivative SF7-12, with 1st Gen node devices (introduced 1-2 years before the concentrators were available) SX127x mirroring this (72,76*,77,78). Later variants for both platforms introducing SF5/6 support (e.g. SX1303, SX1262 etc.) (For completeness 128x node devices for 2.4GHz).
Specialist derivatives/later products e.g. the LR… family for e.g. location based service implementations also potentially support lower SF’s. (With some LLCC68 dropping higher SF support depending on BW!)
TTN long pre-dates the latter offerings and so SF7-12 support de facto for the Community use, though for private deployments of TTS you might look at SF5/6 support (& FSK). To maintain compatability and to avoid community fragmentation stick with the existing standard.
One explaination I heard some years ago wrt choice of SF support was that the LoRa coding implementation (a digital system) added a benefitial coding gain (approx 7-20db equivalent) to classic legacy modulations pushing closer to the Shannon limit but with an obvious silicon overhead, adding to device cost. As the cost was inherent in the schema due to need for similar on chip infrastructure was a fixed amount irrespective of chosen SF; with an additional overhead down to memory, which scaled with SF. It was decided that the min SF commercially viable was SF7, with >SF12 leading to too large a device for little extra perceived benefit and with lower throughput. The codec maths scales ok and so SF6 SF5 and indeed SF13 ‘could’ be implemented but judged not viable.
With later generation devices the process tech allows for lower proportionate LoRa ‘digits’ area and lower cost per die of the LoRa infrastructure overhead, making SF5 & 6 a worthwhile addition for those closer range (possibly in building) networks that can derive useful application benefit, especially in the face of potentially increased throughput they support.
(*) IIRC SX1276 supported a form of SF6 implementation but this is not compatible with later generations(#), and is NOT backward/forward compatible, and I personally have never seen it used in anger in a deployed system.
(#) See 6.1.1.1 SF considerations from the SX1261/62 DS rev 1.2 2019 (GIYF). Note well it also cautions that for reliable detections at these SF’s and associated DR’s you should use a longer pramble and more symbols which of course moves us even further from a common platform implementation and standard for use on the community!
Note before anyone calls out why are you talking SF when discussion largely around DR - I would note that DR’s are somewhat regional dependent and any lack of support is basically largely a function of what SF’s the underlying silicon is designed to support.
Did this quickly largely from memory, and a bit rusty on details, so there may be gaps/errors! If in doubt check Datasheets!
Update: just seen Nicks comment/question re radios - took me a while to type up initial response as muxing with family supper prep! - more a baseband issue than ‘radio’ per se as the radio bit is largely down to seperate FE’s for for Conc implementation and its the codec/modem bit of the integrated node devices which handles the SF and hence DR implementations. The radio portions impact more on the RF behaviour (image/co-channel/adjacent channel rejection, noise performance, raw RF sensitivity etc.), and by the time we are into evaluation bulk SF/DR performance, capabilities and characteristics the RF sections have largely done their stuff (AGC/frequency offsets and feedback, control loops and XO/TCXO perfomance and adjustments not withstanding).