I see you've identified the following problems:
Repository layer sends raw data from the network api to the ViewModel forcing VM to do transformation and formatting making VM hard to test
A "God Repository" that is referenced in a large number of places throughout the codebase
Data transformation logic varies across different consumers (ViewModels), so there’s no single, consistent transformation
You've listed some solutions that sound like they'd help. But let me propose something:
Create behavior code that doesn't know how to find anything, doesn't transform the format of anything, and doesn't decide where to put anything. It does one thing, on the one format it expects, that gets handed to it, and puts the result wherever its told to put it.
This is not what a Clean Architecture use case does. A CA use case knows where to find everything. Knows where to put everything. Knows how to transform everything. And that's fine. A CA use case can use the above behavior code to do its work.
What this does is separate behavior from knowledge of the world. That way when the world changes the behavior is minimally impacted. It also makes the behavior code easy to read (since its assumptions are simple) and easy to test (since you can drop it into any world you like; Even a testing one). This follows the teachings of functional core, imperative shell.
It also follows a less grandiose teaching. Humble Object simply says if an objects logic is hard to test then move that logic somewhere else easy to test.
Doing that will push back on all three of your problems.
When your behavior code insists on a single format you're forced to do the transformation first, outside of it. This avoids crazy conditionals or weird parsing in the behavior code.
This pushes knowledge of all the repositories away from the behavior code
Since all behavior code insists on its own format, transformation logic is pushed out.
But there is more work to do. What you call a "God Repository" reminds me of a service locator. The cure for that is Dependency Injection. Old schoolers, like me, see DI as just a fancy new term for reference passing. I've talked about this stuff before.
You talked about work being done in little helper methods. Consider maintaining the separation they were providing but be willing to make these into full fledged objects (preferably immutable ones). Give your behavior code some respect.
Let me react to your comment:
Let’s say we have a large app where user data is fetched from a remote server. We have a Repository that is used in most ViewModel's. It connects directly to the network layer and simply returns raw data (a UserDto object from an API). Now imagine one ViewModel wants to show the user's full name in uppercase. It fetches the raw data from the repository and then formats the name manually — inside the ViewModel. Another ViewModel does something different, like displaying just the first name with a greeting. Again, it formats that directly inside the ViewModel. - developKinberg
Uncle Bob has a very different idea of what a ViewModel is than the MVVM people do. Since you said your code base is a mix of both CA and MVVM I can't be sure what you're dealing with.
But, in either case don't you have views? Or presenters? Or whatever you want to call them? Somewhere something has to know how you want that name displayed. I see no reason to let that detail leak into your data model. Formatting the name "manually" seems to be the thing to do. But code that knows how to format it and code that knows how to get it don't have to live together. Separate these concerns. Even if you make the CA use case responsible for the transformation doesn’t mean it can’t make some behavior objects do it.
Call them whatever you like. Just use names that make their jobs clear or they'll fill up with clutter.