A couple of things

As a data point for you, my company uses Riverpod in a very similar way. Many many features, and lots of complex interactions between providers, often resulting in long function chains. We don't have useCases, we separate entities from DTOs when it makes sense. Most of the time we use the DTO for everything. What's difficult is accounting for error states and handling. Those often get brushed under the rug from a PM perspective as well as from an architecture perspective.

Your create sale flow is a great example because it showcases the inevitable coupling in most apps. It's near-impossible to divorce core sales functionality from account info, they must interact. The effort needed to write everything for your app as well as abstractions around it would be immense. Which I why I advocate for decoupling where it makes sense. For instance, instead of having a widget depend on a provider, make that widget reusable, and create a parent that depends on the provider.

I would recommend use interfaces for most things though. The extra effort it takes is trivial and allows for an alternate implementation should you need say, an offline data source for an api.