I wouldn't necessarily change just because something is verbose. Even this method is more verbose (using stateful widgets and builders) than some other state management options.

One advantage of bloc is that you can save all of the events. This would be useful if you wanted to add an undo feature to return to an arbitrary point in time. I suppose you could also do that with the minimalist approach, but you would have to be very intentional about how you managed the state. This comes built in with flutter_bloc.

There are two main approaches to handling streams. One is to pass the stream (or possibly a transformed stream) directly to a StreamBuilder in the UI layer. The other is to handle the stream in the state management layer and update a value notifier every time there's a stream event. I would guess the first option is probably the most common, but I use the second option (see the background audio tutorial for an example).

I wasn't familiar with maybeWhen. I see that it's a part of Freezed, which I haven't used beyond simple experimentation. (I've tended to avoid code generation.) Andrea's article about Freezed states, "we use the .maybeWhen() method generated by Freezed to extract the isLoading and errorText variables we need. In this example we need to do this because we can't map the noError, error and loading states directly to specific widgets." If that's true, then my answer for preferring switch case (with sealed classes) is that I can map noError, error, and loading states directly to specific widgets.