Yep, hope Zebra doesnt go and 'spoil' further what was once (still is, and hopefully will still be) a great framework by adding more JS to it
While there is a similar issue with Rhodes Ruby MVC, it is not as severe. While it is true that Rhodes Ruby controllers are single-threaded, when you use some API that is asynchronous, it actually proceeds in another thread. So, for example, your Network request proceeds in parallel, even though you might hog the controller thread with a bit of computation.
That can still happen if you work in JS, IF the asynch API call actually got sent across to the Rhodes core.
And, in Ruby, you have the ability (still only on SOME platforms, such as iOS) to actually use Ruby threads and write actual multi-threaded code.
When you work only in JS, there are many gotchas to watch out for. It is limiting vs. the Ruby environment. It really just proxies into the core APIs, but you do have to make sure your JS doesn't step on it's own tail and prevent the calls from ever getting proxied in the first place. Then you get a result and it is proxied-back, and you have the same concern. Busy thread is busy thread.
I have no quarrel with the existence of the JS APIs - if you don't need them, you don't have to use them. But if you do a large project in Rhodes, do yourself a favor, and learn Ruby.
There is a very important use case for the JS APIs, and here you do not have a choice - you have to live with JS and it's limitations. That is when you want to change app behavior by downloading some code from a server. Most App Stores will not permit this with native code. For example, the Apple App Store simply does not provide a mechanism for this. If you want to update native code, you need to go through the entire app approval and update process.
But JS code is not subject to this restrictions - at least not a technical one. I do think it is a grey area, and so you shouldn't get carried-away with it. I think that Apple will object if you make major changes to app functionality without going through the approval/update process. They allow you to change JS I think partly because there is no practical way to place a technical limitation on it, and because they really have an expectation that you will only use JS for UI. Even there, though, change your UI completely overnight, without an app update, and Apple notices... hmmmm....
Apple is the most restrictive app store, others are more forgiving.
I use a lot of JS in my code, but it is for dealing with UI issues that are very close to the user. I use it because it is appropriate for this. I can also see using the Rhodes JS APIs in limited circumstances where some functionality might have to change on-the-fly and so in specific situations on specific pages or parts of your app. You still have to not get crazy with it, to avoid alerting the Apple bloodhounds.
I can see some scenarios where updating your JS in an App Store app without going through update/approval could easily create a "banned for life" situation. The most obvious that comes to mind would be to make changes via some downloaded JS that add some "phone home" capability that sends some private information (or any information, without disclosure). Apple will not have discovered that during the approval process, and now all of a sudden the app is sending some data somewhere that it was not doing when the app was approved.
That said, I would not be surprised to find that there are many PhoneGap/Cordova apps in the App Store that have done this. It is probably the biggest consumer risk on the App Store. I would equally assume that Apple keeps a close watch on PhoneGap/Cordova apps after approval. We are lucky in a way that we probably fly a bit under the radar.