The only limitation of the Automation library that I have encountered is that while while batch-reading a property across a collection works (.getProperty)
Collection -> .propertyName -> List of values - one for each collection member
… in the first two releases of the JavaScript for Automation the corresponding .setProperty has only been applicable to one collection member at a time.
Examples might be:
- Instead of being able to set every row in an OmniOutliner outline to something like .collapsed, with a single property assignment, you have to iterate across the collection, setting the property for each parent row.
- Similarly, on an OmniGraffle canvas, rather than setting all lines to red with a single property setting, you either still need (in the current JXA) to do it iteratively, line by line, or use a function like evalOSA, to do the batch setting with an AppleScript line from inside JavaScript.
Generally JSC (JavaScript Core) itself is a very mature and highly optimised language, which has benefited from many more iterations of competitive improvement than AppleScript, but the Automation library is very new, and has been through far fewer iterations than AS. As long as people are using JavaScript for Automation, each iteration will enrich and develop it. The only thing I am looking for at the moment is the batch setProperty over collections.
(And probably someone needs to write an good book, if books still sell 
)
(There’s also really just one disgruntled voice which aimed to set a certain tone for while – that of someone who had (a) written another automation interface for JavaScript, based on Apple’s older and now largely deprecated Carbon interface, and who really felt that ideally his project, or at least his advice, should have been adopted by Apple, and who had ( b) written an AppleScript book.
An understandable reaction of disappointment, but it seemed somehow to mutate into a curiously foul-mouthed and over-insistent attempt to dissuade others from using Apple’s JavaScript for Automation at all, which has left a marginally less than fragrant trail in StackOverflow. A difficulty with this campaign was that the writer felt impelled to dive in first on any technical question and encourage an impression that the whole thing was broken and that a solution was unlikely to exist and that the language ideally shouldn’t be used. The actual technical solution might be quietly offered by others some time later, but by then the propaganda effect had been achieved. All’s fair in love and war, I guess, but I think it would have been a bit more helpful to the public had this voice been slightly more punctilious in declaring an interest (disappointed authorship of rival interface, authorship of book which risked loss of readership, heavy personal investment in AppleScript etc).
But fortunately, the sheer usefulness of JavaScript for Automation speaks for itself.