I have used Marmalade/Airplay for almost two years now in my indie game company. For me it's a win because I'm just one programmer, and I can do virtually all my work in Windows using MS Dev Studio (which is my favorite dev environment by far) and because it shields me from having to deal with a lot of the platform-specific details, especially with the various development tools, that could eat up a lot of the time I'd rather spend on game content.
Speed will not be an issue with Marmalade. Your C++ code runs natively. Also, access to camera and other functionality should not be much of an issue; it's either already provided or can be added using the extensions SDK, which is pretty straightforward to use.
Marmalade is a mature product and the company is pretty helpful in resolving issues quickly, even for indie developers that are using the product for free. In addition to the cross-platform-ness, it has some nice tools built in, such as a memory leak tracker, a logging system, graphics analysis tools, and others.
There are some downsides that I've experienced with Marmalade.
Even though in theory any API or third-party SDK is accessible through the extensions system, in practice the thing you need may not exist yet. As an example, a number of developers are currently struggling to get the analytics package Flurry integrated, and it's been a challenge for some. The situation is similar with lots of other third-party SDKs; they may be just a couple lines to integrate if you are doing Objective-C development, but can be more difficult via Marmalade.
Some things are less natural because of the cross-platform layer through which you operate. Some examples for me have been:
I've had trouble getting my splash screens (application start-up screens) to display properly in all screen sizes on both iOS and Android. And it's been hard to get them to show without some flickering, short black-out periods, or resizing of images as it transitions between the device load of the Marmalade app itself, and then Marmalade's step of loading your app code.
Marmalade imposes a very simple memory model, where you get a fixed heap up front, and all memory allocation is done through Marmalade. From the system's point of view the app just has and keeps a big block (or a few big blocks) of memory. This has some advantages, but I've had problems squaring this model with the iOS model of, for instance, receiving memory warnings and being expected to jettison any unnecessary resources. It appears to be a case where "one size fits all" ends up actually losing some key functionality.
You can use the extension manager and some other methods to show native UI elements, but integrating a significant amount of native-look-and-feel UI can be a challenge. So if your app is game-like and users can deal with non-standard buttons and so on, that's fine, but if you anticipate needing significant native UI, it is harder. [edit: Recent versions of Marmalade have added a native UI framework that lets you specify standard UI elements in a generic way and then implements then using the appropriate widgets for the device. I have not used this, but it looks fairly comprehensive.]
If you run into problems, it's often not clear whether it's a generic OS problem or a Marmalade problem, and it can be lonely trying to find help. For instance, I recently added in-app purchase to my game, on both iOS and Android. IAP is challenging, and even without an additional SDK layer there are lots of special cases to deal with. In my case, I had a situation where my app had been rejected by Apple for a small issue, and while it was in the rejected state my in-app purchase was also in a "rejected" state (even though there was nothing broken about the IAP itself; this is just a quirk of Apple's process). When I was trying to regression test the in-app purchase functionality (while I was submitting the fix for this non-in-app-purchase-related issue), the game was actually crashing, instead of getting an appropriate error result. I was able to determine that the crash wasn't in my game code, so it was either the OS (unlikely) or the Marmalade middle layer for handling the in-app purchase callbacks (which is what it turned out to be [update 11/28/2012: Marmalade has reportedly fixed this problem in a recent SDK update]).
So in a situation like that you can try going on Stack Overflow to get help, but really nobody is there to help you, so you are dependent on the Marmalade team to get back to you with an answer. As I say, they do a pretty good job of this, but there's no way it can compete with nearly instantaneous responses on Stack Overflow from the world-wide community of regular iOS programmers. So I'd say this last one is my biggest concern with using a system like Marmalade. It saves you time up front not having to come up to speed on the details of the various platform SDKs, but when you run into problems you are "at the mercy" of the Marmalade team (or friendly Marmalade community members) to get back to you with an answer. (Keep in mind here that I'm writing as a freebie indie developer who just gets standard priority for issue resolution. You can pay to get guaranteed quick resolution.) For me personally, it's been hard having to keep coming back to my producer and saying "I'm waiting for an answer from the Marmalade guys on this one."
(Another example of issue 3 is that until recently there was a problem with sound effects being delayed on certain Android devices. It was a Marmalade issue, and they did eventually resolve it, but it took a while, and there's basically nothing you can do in the meantime.)
Keep in mind that (as other responders have pointed out) even without Marmalade you can still have the bulk of your code base in C++ on either iOS or Android.
In spite of the long list of potential issues above, I am a fan of Marmalade, and I appreciate all the company has provided for me for free. The tool really shines when it comes to other platforms that you'd otherwise never bother with, such as (for me) bada or PlayBook. You really can deploy to a wide array of devices from the comfort of your PC and Developer Studio (or from a Mac with xcode, if you want to make your life a little harder ;). The simulator tool they have is great, and there have been only a small number of instances where I've had to debug on the device itself; in general if it works on the simulator it just works. IdeaWorks has taken on a huge challenge and they are doing a great job juggling all these features (i.e., basically every features ever offered on a mobile device) on all these platforms (i.e., all significant devices in existence, with the exception of Windows Phone 7 because it does not currently allow native code). It just comes with some caveats.
