I know state management is a hot topic. And your skill level isn't the target audience of my article. Beginners like "magic".

The truth is, Riverpod isn't magic. Providers are just global token / containers that communicate with the ancestor ProviderScope. This architecture has several advantages, like compile-time-safeness and full testability. All tests can run in parallel because of isolated scopes. It's also possible to simply mock away a certain Provider reference in test. This huge for everybody who actually tests it's app.

The read and watch are also plausible. When watching you subscribe to any value changes, while read access the stored provider once. (Maybe "get" would be a more consistent name for that). But I get that it might be confusing the first time. :-)

Then you have different Provider types that relates to different code strategies. I also like the ChangeNotifierProvider cause I like ChangeNotifier, too. A single notifyListener() and BAM everything updated. That's all very easy to do with Riverpod.

You have a Future-based API? FutureProvider! Stream-based API? StreamProvider! You can compose all those providers to apply after request filtering at a single point. (See my "functional global variables" example)

Riverpod is actually what you describe. Having business logic away from UI code. Put those Providers into your "business_logic" directory and you are done.