Cost - a.k.a. "And here I was hoping to retire some day"
Dare I go so far as to say that cost is the number one stated reason that people stay away from LiveCycle Data Services?Everybody loves a free ride, but developing a set of tools as complex as LCDS requires a highly-skilled team (i.e. "it's astronomically expensive"). To recoup that cost usually means one of two things: sell a large volume of licenses or charge a lot for a few. Frankly, this question is way outside my realm of expertise: how exactly do you price something with so much undeniable value but that is very costly to create and maintain?Some well-respected voices in the Flex developer community have gone out of their way to express their unhappiness with the LCDS pricing model. They want to use LCDS but in some cases can't because their customers simply can't afford it. If developers know/assume that their clients can't or won't pay for LCDS, they won't promote it and likely won't even bother learning how to use it (which can contribute to my second point below.)
Ignorance - a.k.a. "L. Seedy Hess... Who dat?"
This is, to me, the number one unstated reason. (Admittedly, that I hold this opinion may just be a symptom of my own prejudices.) Some developers simply don't understand the benefits of using AMF and remoting, etc. (this point can therefore apply to both LCDS and BlazeDS) They understand and trust SOAP and XML and the simplicity of REST-like web services, so they default to WebService and HttpService calls over LCDS. Consequently, their apps end up architected a lot like "standard" web apps, which can be all fine and good, up to a point.If you're reading this and either a) don't know anything about the benefits of LCDS or b) don't see a benefit to using a binary protocol for streaming data to your Flex client, please check out James Ward's eye-opening Flex data transfer benchmark tool, for starters.
Intimidation - a.k.a. "Fear of the nuclear option"
LCDS has a certain "only the big boys use it" reputation and therefore, some developers nervously back away from any mention of it. I call this visceral and perhaps irrational uneasiness "fear of the nuclear option".This point also applies to LiveCycle in general: many people just don't understand what it really is, so in their psyche it remains in the category of things best left to the rarified air of Olympus (i.e. "code of the gods"). Perhaps that perception is something that Adobe could help with.
Habit - a.k.a. "I like wearing what's left of my lucky gym shorts"
Some developers come from a more "static" web development background. They are used to and enjoy writing pages built with HTML forms (or hyperlinks containing URL-encoded parameters) and submitting data to a server that builds and returns more HTML (e.g. JSPs, PERL, ASPs). Some of these people are perfectly happy with the limitations of a synchronous, more "old-school" web application development approach (i.e. build, render, submit, build, render, submit). Others prefer to simulate real-time behaviours using an AJAX framework. Whatever the reason, they see no pressing need for (quasi) real-time data updates and a strongly-typed object model on the client side that mirrors the one on the server side.
It's Overkill - a.k.a. "Bring a nuke to a pillow fight"
In some cases, developers do want the speed of binary data transfer and the convenience of sharing a strongly-typed data model between client and server code but simply don't need the scalability and push capabilities of LCDS. Those developers will often stick to BlazeDS because sometimes, polling is good enough. You really have to analyze what your client's needs are before making these important decisions. I've probably chosen LCDS over BlazeDS (easy call) in certain situations because a customer is using LiveCycle and already has a license for LCDS whereas I might have otherwise settled for using Blaze. As with anything else in life, the decision becomes a little more difficult when there is an additional cost attached to it.