The Elm and Reagent (Clojurescript) communities build apps this way. It's theoretically possible to do everything in render in practice you wind up wanting to do things in other lifecycle events (e.g. display a google map) in most apps. There isn't any component local state but the components aren't pure render functions either.

In general, interacting with anything that does more interactive rendering (three.js, google maps, ads, etc) requires access to lifecycle events beyond a simple render method...

In the past I've had to keep a handle on the DOM nodes for ad slots that may hide/reshow when a window was re-sized, so the same ad was kept.

However, this should be the exception to the rule, and I still love the React way over components (Polymer) or angular directives.

That should be possible! Of course, stateless components don't have state, so you would need to something like Recompose if you need that. And of course, not all React-related projects explicitly support stateless components at the moment (e.g. hot reloading).

Another option is to use psuedo-local state with Redux and pass everything as props: https://github.com/rackt/redux/issues/159. As Dan notes in that issue though, it might be better to wait for the state tree model to be improved: https://github.com/facebook/react/issues/4595.

In short: early days, too early to tell what patterns will emerge.

I generally try to do everything in render(). It almost always works out better. Sometimes I end up needing a lifecycle event. Timers (e.g., for manual animations) end up being hard to model without mount/unmount.

Agreed.. using mount/unmount is the exception to the rule.. I can imagine anything using charting libraries, or any third party rendering library would need to do this for performant controls... but it is definitely the exception to the rule.