setProps - depends on reading the last reconciled props from the current reconciled state of the app, at the time of the call. It also depends on an object that doesn't necessarily need to be there outside reconciliation. This is unlike setState, which is state that needs to be there. setState is queued up and merged at the time of reconciliation. Not at the time of the call. setState has a side-effect but is not a stateful nor mutative API.
isMounted - reads the current state of the tree, which may be stale if you're in a batch or reconciliation.
getDOMNode/findDOMNode - Reads the currently flushed node. This currently relies on the state of the system and that everything has flushed at this time. We could potentially do a forced render but that would still rely on the state of the system allowing us to synchronously being able to force a rerender of the system. Note: in 0.14, refs directly to DOM node will resolve to the DOM node. This allow you to get access to a node at the time of its choosing. findDOMNode/getDOMNode can be called on any composite and assume that its children have all rendered (to a single node) at that time. This means that it relies on the state of every intermediate composite instead of just the lowest level.
"owner" - The "owner" concept relies on being able to track a shared global state flag at the time of creating elements. This means that we have to create a dependency into a single shared global stateful module for all React components. It also means that effectively no React render function is truly a pure function since creating an element depends on global state. It is not idempotent. That means that you can't reliably use things like memoized functions and all kind of other functional goodies.
These APIs all inhibit the declarative powers of React.
Technically
this.propsandthis.statehas similar problems. Maybe I should've included that in the quiz? But it is not inherent to those APIs if the callers can be wrapped so it is not quite as clear cut.