StatefulWidgets are just fine when you need ephemeral state for a widget that has a lifetime coincident with the widget and survives between builds. Yes, for any state that is shared beyond this scope or lifetime, you'll reach for a state management solution (my preference is Riverpod). But it seems like you're throwing the baby out with the bathwater in this video. The proper stance is a bit more tolerance.

Now I completely agree with you. 😀 You summarized it in very simple and understandable way. Bottom line: avoid to use them as much as possible. 😉

People not really understand StatefulWidget widget. StatefulWidget have more important things as set state. To change state you use ValueNotifier or any other state management. StatefulWidget used to check widgets life circle as on dispose, init state and the rest. All important elements in the Flutter is based on the StatefulWidget.

Except for text controllers / other controllers, custom widgets you make, when you need a simple callback not tied to bloc so you can reuse it, when your passing copies of bloc as a parameter so you don't have app wide scope of the bloc...

Most of the flutter related debates seem to have already taken place in the reactJs community I suppose. Using state in component may not be a useful as states need to be lifted and hence Redux, etc. Have seen similar vids where all the debates seem like deja vu :) Maybe someone has to do a vid of the similarity between React and Flutter, from a comcepts point of view (even build() is similar to render() ).

It would be interesting to watch about navigation tools)

Just a note: Your current thumbnail says "StatelessWidget sucks" but this video is about StatefulWidget