I don't think there's going to be some peer reviewed study that you can rely on or a simple empirical model to draw from; even to the extent that such a thing might exist, proving that the data fits your situation might be pretty hard. The fact that such model fitting is so impractical is the reason that business tends to rely so much on surveying "case studies" of what is usually a single company or team that changes practice x to y (or supplier a to b). The narrative fallacy is often at work, but it's one of the few tools that have any sort of traction outside of pseudoscientific neo-Taylorism, because people have an incredibly good pattern matching ability and have an intuition (whether justified or not by other data) whether a given case study has any lesson transferable to their situation. I think this sort of case study dependence can be as intellectually bankrupt as "scientific management" was, but that won't stop people from using them.
The thing to measure really is development friction. You won't be able to predict exactly how a strong domain model can affect velocity, but if you start with an anemic domain model and start encouraging moving more business logic from service layers into the domain layer, and encourage frequent refactoring as you gain a better understanding of the domain, you can at least draw comparisons of velocity (if you're using something like story points to approximately measure task complexity), or customer satisfaction, or fragility of the system, or test coverage, or whatever resonates with your organization.
Based on my experience, I'd guess you'll find some initial hurdles as you start changing practices, as you'll likely have to deal with some nasty side effects and existing technical debt, but that you'll have a long term payoff if you make progressive investments in a real domain layer.
If you're trying to make the case that you need to move away from an anemic domain model, the best thing to do is provide data on what's hard to change now, what customer requests take longer than they should because you have to change code in four different places instead of one, for example. As I frequently argue, the best case for change is identifying the pain points of the existing system; working code will start winning any arguments about whether you're on the right path. Rather than focusing on delivering cost estimates, focus on a narrow scenario that you need to deliver near term business value on, and start attacking the problem by firming up the domain model.
To be case-study-ish without naming specific companies that I've dealt with this problem in, here are some problems that projects I've worked on with anemic domain models had:
- Duplicated or slightly divergent business logic in multiple layers of the system, not enforced at the domain layer.
- Poor developer understanding of business rules, because the actual business logic is spread around the system. This alone tends to result in lots of bugs.
- Slow turnaround time on feature enhancements, or major functional regressions and bugs as a result of new feature work.
- Unexpected side effects of code changes. (Typically, some bit of code assumes that some other part of the system kicks off some sort of asynchronous process or autonomous transaction, but doesn't have a way of verifying that it occurred, and a new developer doesn't know about this behavior or an existing developer forgets about it).
- A big divergence between the way developers talk about the system and the way users talk about it, resulting in cognitive friction when trying to make sense of new requirements.