(disclaimer: I work for Adobe on a competing service (PhoneGap Build) and have worked with PhoneGap for years)
This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once.
The bridge in PhoneGap Android probably is slower than the one in Forge but
1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release.
2) synthetic benchmarks aside, there's no indication this would affect the usability of the app.
Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip.
With PhoneGap:
* first half of the trip (7ms)
* Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively)
* second half of the trip (7ms)
= 514ms
With Forge:
* first half of the trip (1.5ms)
* Android presents Camera activity, user picks a photo, Android returns control to original app (500ms)
* second half of the trip (1.5ms)
= 503ms
This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.