I'm very sensitive to the concerns you've raised in this thread. I've discussed these issues quite a lot, and ultimately decided that it's better to provide a net win to the React Native tooling ecosystem, and try to smooth out the gaps between React Native and Expo. I do think CRNA is a good improvement over the current state of "getting started" in React Native.
Regarding your concerns about "private entities," React Native is open source. Expo is open source. React Native was created and is maintained by Facebook, a private entity. Expo was created by and is maintained by Expo, a private entity. Do you have the same concerns about the recommendation in the RN docs to use Airbnb's maps library?
In order to use CRNA, you need to have a client that can fetch and load the JavaScript bundles. CRNA is agnostic to which client you use, which is why app.json puts any Expo specific configuration under an `expo` namespace. Anyone is welcome to implement their own client and use that if they prefer. I'd be very happy to review PRs which support loading React Native JavaScript in an alternative client. As an implementation detail of the Expo client, a number of native APIs are exposed, and it would be infeasible to block CRNA apps from accessing them.
We don't push users towards the Expo SDK, and the template project doesn't make use of any Expo APIs. If users choose to include a dependency on Expo's code, then we warn them that ejecting will break that dependency -- that's it. We choose a default choice in that prompt on the basis that we don't want to push users towards breaking their app.