In our capacity testing we've seen collision rates at about x2 this rate because of up/down collisions caused when the gateway is ACKing or sending MAC traffic. I our testing 1000 25 byte SF7 transactions per minute with 5% ACK/MAC downlink result in 67% message loss using standard 8 channel LoRaWAN. This does get better with more gateways, as the downlink traffic can be shared. SF11-12 Downlink is extremely harmful to the network. This testing was not compliant for 1% gateway duty cycle, as it was for the US market.
This is one of the primary reasons Symphony Link from Link Labs (currently only for 900 MHz) was built. You need a synchronous system to coordinate TDMA/FDMA and (SF)MA, along with MAC ACKs. The 1% duty cycle limit in 868 MHz is the reason that LoRaWAN has to use this Aloha scheme, which results in a high collision rate. 1% also dictates very few ACKs, which is good for capacity, but bad for reliability.
With LoRa, ANY LoRa traffic affects the gateway baseband modems the same way, whether or not it is part of the same network. This is compounded if the public/private PHY header is not being used (which the Alliance is proposing). If TTN, an operator, and several private networks all try to coexist, the interference could be fierce.
In Symphony Link, because of the higher rate frame header transmission (every 2 seconds), nodes can automatically set SF to match the link, and the gateway can actively move uplink channels around based on other interference it is seeing. Symphony Link also compresses all acknowledgments, info blocks, and downlink for the frame into a signal message, which saves on preamble time-on-air over the LoRaWAN unicast architecture.
To @JamesC 's point, assigning some sort of slotting with CSMA to the LoRaWAN uplink scheme could as much as double the capacity. I'm unsure how this could be coordinated though, without more gateway transmissions.
The attached Whitepaper from Real Wireless goes into these and other considerations.
Real-Wireless–LPWA-2016.pdf (1.4 MB)