I guess I understand that for simple component. The checkbox here is a good example where the value is the state, so there is no use in keeping an extra copy of it. Same would be with a slider component or whatever. But when it comes to more complex components I always feel like encapsulating functionality makes the component more reusable and less boilerplate-y which in turn encourages use. It's sort of like convention over configuration.

But then again, maybe it just hasn't 'clicked' with me yet.

Edit: I should say though that having all state external would help in testing the component since you can now simulate every possible state without going into the internals of the component itself.

I'm not religious about keeping components stateless. I have some components where I just found it was getting too complex to keep bouncing the state up and down the hierarchy so I just merged it all into one big stateful component.

If I was a better programmer I probably would have known how to structure it properly to avoid this but I'm not.

Also recently I have gone to the trouble of learning Redux which effectively provides a mechanism for global state and probably that would remove much of the problem with moving state around. But this is the thing about programming - you build your code doing it one way, and 80% into your project find a better way, which you start using. Hmmmm.... now should I get the damn thing built and have the app use two (or more) ways of getting the same thing done, or go back and make the whole app consistently use the better way, or not use the better way and instead continue to use the old way but keep things consistent?