In my opinion part of the problem with Bluetooth is that the API exposed by android and IOS is like... two or three layers too low. Imagine if in web programming you set the MTU size in your HTML and you get the idea of what programming Bluetooth is like.
Another issue I see is more of a view point that people have trouble shaking. Typically we think of the server as being more powerful than the client, but in BLE the client usually has more processing power and battery by several orders of magnitude. Once you examine this preconception BLE makes a whole lot more sense.
Compared to HTTP/TCP/IP, abstractions between layers of the BLE stack are extremely leaky. Examples: indicating choice of PHY coding and channels in the equivalent of a `listen/connect` call, or the three different but intertwined places where fragmentation/reassembly can happen. Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs. By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
I suspect this is due to not having enough independent implementations of each layer - Bluetooth is designed and standardized by one committee, and the entire stack usually implemented as a single "thing", making it too easy to break abstraction when a new feature needs to be added.
> By comparison, being effective with HTTP does not require one to know anything about the PHY layer, or TCP stream reassembly.
Maybe not PHY, but you definitionally need to understand TCP, in fact, you have keep-alive and timeout headers that are directly related to TCP. Further more, HTTP/2 is a whole another level of leaky when it comes to HTTP/TCP.
> Being effective with BLE requires deep understanding of the entire stack, and since it is difficult for a single person to have such level of understanding, we get bugs.
Bluetooth or LE? LE with GATT in my experience deals with none of this. At least not on an Apple product, CoreBluetooth hides all of this from me as an iOS or macOS developer.
Apple does hide most of this, but consider that an iPhone app isn't the BLE product most developers are building, rather it is the device that iPhone app talks to, and where the bugs lurk. (Not that Apple doesn't have its fare share of BLE bugs at the chipset/driver level, which resurface with every new iOS release.)
Another issue I see is more of a view point that people have trouble shaking. Typically we think of the server as being more powerful than the client, but in BLE the client usually has more processing power and battery by several orders of magnitude. Once you examine this preconception BLE makes a whole lot more sense.