We intentionally chose to not let users drop down to native -- the idea of having an interpreted language that sits on top of a native runtime on multiple platforms is not a new one, and it allows for so many benefits that you lose out on if developers can add arbitrary compiled code with direct access to system APIs.
Additionally, there is a significant value-add of using Exponent in terms of upgrades. As great as React Native is, it also moves extremely fast and it can be difficult to keep up with new releases -- a change in React Native might cause several of your native dependencies to break, and you'll need to fork those libraries and fix them if the maintainer isn't keeping on the same schedule as you. Updates with Exponent are as simple as updating JavaScript, which has much less churn and breaking changes than the native side (the React API itself is very mature, the APIs for specific native components may change).
Another nice advantage of this is that you can work on an iOS app from Windows and Linux, because you don't need to compile your app with Xcode (we handle builds for you when you want to ship to the app store, before that you can just use the Exponent client).
We ship with a bunch of APIs out of the box and are constantly improving them and adding more. We have analytics tools like Amplitude and Segment built in, Maps, Facebook login (working on Google Login), and more: https://docs.getexponent.com/versions/latest/index.html
React Native is still very early, though, and Exponent is just a small team of seven, so we understand that we can't possibly expose every API that developers working with the platform might want. So, we are working on a way for developers to be able to still take advantage of the Exponent toolchain and layer on native code. I've written up our approach in more detail here: https://blog.getexponent.com/answered-on-slack-ejecting-from...
Sounds like at the end of the day it comes down to Exponent being committed to the user never having to build their own app. I can see that being interesting a to a single dev, or a small app or someone new to mobile development, but to be honest I don't think I could justify using Exponent at a company. On any reasonably experienced team of developers, building an app when native components change or distributing it with something like hockeyapp is not very difficult, so I just wouldn't trade the flexibility of being able to do tricky parts directly in native code for not having to build the app.
Exponent maintains native modules so they continue to work when React Native changes or when Android & iOS change their APIs. In particular, React Native is released every two weeks and we stay on top of the changelog so you don't have to regarding native modules. We also write native code for both platforms in tandem, often by the same engineer, so that we get coherent APIs that cover common features across both platforms and expose platform-specific capabilities neatly. We want Exponent to feel like a coherent project. All of the docs (and code) for Exponent's modules are in one place, and when you download the Exponent app for development you get all of the native modules right off the bat.
As a data point, the Android version of Li.st (https://play.google.com/store/apps/details?id=st.li.listapp) is built on Exponent and was featured by Google in the Play Store. Li.st is currently one of the best examples of how far you can go with Exponent, and React Native for that matter. We're also on Slack (get an invite here: https://slack.getexponent.com) if you want to chat in real time.
From the FAQ (https://docs.getexponent.com/versions/v10.0.0/introduction/f...):
"But no native modules...
The most limiting thing about Exponent is that you can't add in your own native modules. We give you most of the most commonly desired things, but if you need something very custom--like on-the-fly video processing or low level control over the Bluetooth radio to do a firmware update--then Exponent won't work for you and you should just use regular React Native."