LoRaWAN does have gaps in the architecture and protocols that need careful consideration from the IoT architect:

• Some features common in LTE networks are simply not designed into the LoRaWAN architecture. LoRaWAN is not a complete network stack in the OSI model. It lacks the common features of a network layer, session layer, and transport layer: roaming, packetizations, retry mechanisms, QoS, and disconnects. It is up to the developer and integrator to add those services if necessary.
• LoRaWAN relies on a cloud-based network interface. At some point in the value chain, a cloud subscription is needed.
• The chip vendor is Semtech and is a single source of the technology, although there have been announced partnerships with ST Microelectronics. This is similar to the Z-Wave value chain. 
• LoRaWAN is based on the ALOHA protocol. ALOHA complicates validation and acknowledgment as well as contributes to error rates over 50%.
• Downlink ability is still limited. LoRaWAn is fundamentally a one-way protocol. In certain use cases that is sufficient, but it tempers flexibility.
• LoRaWAN has high latency and no real-time ability.
• No OTA firmware updates.
• Mobility and moving nodes are challenging to manage in LoRaWAN. A 40 to 60 byte message can take 1 to 1.5 s to transmit. This can be problematic for moving vehicles at highway speed. A base station also requires Linear Time Invariant (LTI) which means the radio waveform shouldn't change the time of flight.
• Geo-location precision is about 100 m. Using RSSI signal strength measurements or time-of-flight measurements, a degree of accuracy can be obtained. The best solution is if three base stations triangulate a node. More base stations can improve the accuracy.