I'm sure doing a similar thing with LayoutManager wouldn't be too hard. I think LayoutManager uses _render internally too so you may want to call it something else.
That's great - benchmark 2 is essentially a bunch of useless work, and it appears to really speed things up by making sure we only actually touch the DOM every 16ms, instead of constantly.
I'd imagine a Backbone integration with React would get us even closer. I'm not sure if it actually makes sense to go too far with an LM conversion as React appears to do a better job. But LM could certainly benefit from waiting until RAF.
About what I'd expect for the first benchmark, but that's the kind of intervention from the user that I think frameworks should not require. The time still spent by Backbone.js on the second one more or less illustrates why I don't believe in event oriented MVCs.
I've been using Meteor for a couple of years now, and although it does a lot of magic, I recommend using it only for very simple projects.
For this application, meteor may be suitable, but keep in mind that you'll need to build a lot of your supporting infrastructure until Meteor 1.0 comes out.
Reasons not to use Meteor:
It is currently very difficult to accurately profile memory issues.
Simple html mixups can take half an hour to debug due to the fact that they'll only show up in production, and in minimized/uglified form.
MongoDB costs 'money' to scale properly (sharding across multiple machines with lots of memory (if your database grows).
Edit: This is not a simple project, so maybe meteor is asking for trouble since it's not very mature yet.
Check the mailing list for this. There wasn't a large amount of discussion about mobile options when I last checked, but one solution seems to be what you've already listed above: Phonegap/Cordova.
