So you come onto a Forum for a network that uses LoRaWAN and ask which is best?! Now let me think for a time 
…
In reality it will entirely depend on your use case and what work you are doing yourself vs what mesh infrastructure from others you are relying (or is that relaying?!) on.
Have worked with legacy technologies, with LoRa, with LoRaWAN and with wireless mesh deployments. Fundamentally mesh works better when there is no restriction on throughput other than the core technology itself (think Mesh Wi-Fi for example) vs when it is operating under constrained conditions. Generally in most territories LoRa is constrained by duty cycle limits, where that does apply there may be issues like dwell time - which then limits practical SF use, or there may be other problems vs straight ALOHA deployments where you must consider e.g. LBT issues. Looking at mesh for e.g. smart metering using wireless/RF solutions long before LoRa emerged and even after LoRa one of the biggest problems I and colleagues saw was the creation of what I christened ‘super-nodes’. These were nodes that by accident or by design or by fluke of RF paths, blockers/obstructions, interference or failures of routing algorythms ended up passing a disproportionate amount of traffic c/w other nodes. This typically has 2 main consequences (1) higher than expected throughput meant that ‘average battery life’ that was originally planned for many years (e.g. water or gas metering where you want small amounts of data delivered on low duty cycle but without need for field service e.g. to replace expensive Lithium Thyonal Cloride batteries less than 10, 15 even 20 year cycles, suddenly needing replacing after just a couple of years, months in some cases (Batteries also rely on chemical recovery after spiked load (tx) to be effective and if pushed too often they can suffer a form of collapse)) (2) higher than anticipated throughput meant that the node would then either block due to more traffic than it could handle (bandwidth/throughput limits of core tech as above) or would block simply because of duty cyce and fact that as a transmitter it had exhauseted its allowed on air time and wasn’t legally allowed to forward. Note in many metering appliction deployments would use licenced bands without such limits vs the classic ISM bands where the limits apply, but the issue still arose at scale. Depending on application you may also see issues with latency - each node essentially being a store and forward device will add a small delay, so how many ‘hops’ sustainable? Most Mesh have a hop count included (adds to payload size with other factors) and a ‘drop after’ policy so having handled across many nodes (consuming resource and energy!) it still doesnt get through and relies on an alternate redundant parallel path to replicate…and so on. Mesh involves sending to downstream nodes, multiples of, and they then… leading to message floods that can grow dramatically if not controlled/managed. Mesh has its place but needs careful evaluation, understanding of use case and consequences and great design and management/control. As noted have used and still use in some cases but for me (TIMO/TIME) LoRaWAN ‘just works’ if you follow the specifications and ‘rules’ and have the right expectations wrt behaviour. 