Hi @hoonppark, I think your analysis is very accurate. It’s very helpful for us to see what we’re doing right and where we should improve.
Some comments / background:
TTN Production Server planned to be released in early 2017: I’m positive that it will be before 2017. We’re almost ready to start public testing with the new version of the backend 
Class A only / no plan for Class B and C: Supporting Class B devices is unfortunately not easy in a network where you don’t own/control the gateways. Additionally, you’d have to synchronize the time of each gateway very precisely. Telecom operators do this with GPS modules, but that doesn’t work for TTN, as most of our gateways are placed inside where they can’t keep an accurate GPS fix. I’m quite sure that we’ll never be able to fully support Class B devices (at least, not in the public community network), so we haven’t spent much time on this. We can (and probably will) support Class C devices. However, keep in mind that this is not really low-power anymore.
Fair Access Policy: There’s not much we can do about this. We just have to limit the airtime of devices in order to keep the frequencies available, this will be the same for any network. Some networks limit the number of messages per day, some limit the airtime per day. If networks don’t limit this in any way, the frequencies will eventually be flooded and nobody will be able to send messages anymore.
Question: Have you checked with telecom operators what their message limits are for different subscriptions?
Documentation: We recently took the old wiki offline, so that already cleans up some old stuff. However, documentation is still distributed over a number of places. Please help yourself and the rest of the community by writing great information on our wiki!
No device management: We’re working on it