That's a... big mobile team. RN's been a good move for our smaller 2-3 person teams (2-3 devs, plus part-time designer, QA, various other roles full or part time—call it 6 personnel) though not without trade-offs. Big wins:
1) JS devs can contribute quickly and comfortably.
2) Can still easily write native code if needed (win over other native-but-not-native frameworks)
3) If you decouple business logic (Redux, even) and, say, REST client code, that stuff's largely portable to an awful lot of platforms. RN's supported platforms (including kind-of supported, like FireTV and Apple TV), plus desktop (well, "desktop"—Electron) and (depending on what you're doing) web.
4) It actually does look pretty OK on both iOS and Android with few special considerations (conditionally rendered sections, different views) for each. This surprised the hell out of me.
5) Papers over a lot of stupid, badly-designed, and/or broken crap on Android, and does a decent job of it.
These add up to a ton of time saved, which manages to overcome:
1) Immature, kinda poorly managed ecosystem. If you stray from RN+Redux and one or two other core libs, Here Be Dragons. Like, good luck ever upgrading RN if you load up on dependencies like a typical JS project, if those dependencies touch RN itself at all. Part of this is just JS "culture", part of it's the relative youth of the project, and part of it's FB's choices.
2) It's Javascript. We've fixed this by using Typescript, which is great. Makes Redux actually manageable—way less bouncing around between files, bouncing out to documentation, more just writing code. Fewer red screens due to typos or related dumb mistakes.
I can see, though, how it'd be challenging to divvy up work efficiently on even a fairly large mobile app for 30 people (are they all devs?!) unless you've got a lot more going on than just layout/CRUD/client-server, in which case I'd think RN wouldn't change things much, as far as division of labor goes.