Not quite sure what you mean. Maybe the RFC might explain the motivation a bit more?

https://github.com/reactjs/rfcs/blob/master/text/0065-contex...

The contextType API serves as a convenience for the most common case of accessing context today. While the existing render prop API is more versatile, the fact is it's awkward in some cases with classes (e.g. when you need to access it in lifecycle).

And unfortunately that means that people are stuck using the legacy context API which is even worse (it makes React bigger and slower). So we're adding a convenience to help people migrate to the new implementation with a slightly more familiar syntax.

I guess in a way it _is_ a compromise, but in our view it's better than if people just kept using the legacy context API.

Hope that makes sense.

ClojureScript dev here, we use the context pattern a lot in http://www.hyperfiddle.net/ and we feel it does not harm our ability to reason about referential transparency

It's just another input. Previously, React derived a rendered set of virtual-dom nodes from `props` and `state`. Now, it' derives that set of nodes from `props`, `state` and `context`. It's useful syntactical sugar.

I felt that way too.

Seems like it’s more of a monkey patch for people who liked “the old way”.