Relay was built to address concerns that our developers faced with managing data in complex apps. Needing to reimplement solutions to the same complex problems (error handling, request coordination, caching, etc) could take time away from focusing on building products. Relay helps to solve these common cases, and it sounds from your comments above ("my productivity has skyrocketed") that you've seen the benefits too - great to hear!
> Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.
We built something that works for us, balancing feature set, runtime performance, maintainability, code size, etc. We're continually focusing on performance - see https://github.com/facebook/relay/blob/master/meta/meeting-n... for more about what we're focusing on - but so far file size has not been the most impactful thing to work on.
As far as understanding Relay's functionality, we've covered the more obvious aspects in talks (http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.htm...). But an analogy to React is probably simplest. React converts declarative UI descriptions into imperative updates on the DOM. Relay is superficially similar - it converts declarative data descriptions into imperative calls - except that there is no DOM for data, so Relay also implements the query representation, object graph for cached data, networking, mutation queuing & rollback, etc.
We're also giving a tech talk about Relay internals (https://relaytechtalk.splashthat.com/) which may be of interest.