Monitor volume of data returned to the client application
Warning: this is more of an soft-skill, wholistic approach answer than a technically oriented one.

I'm not aware of anything that will make quick work of this problem - you did say it was a problem, right? I'm not saying don't  pursue this, but if everything is basically working it may not be worth dying on this hill. That is often why developers are had pressed to care at all, in my experience. However, if there are actual problems and you've narrowed down this is the cause...

It should be pretty easy to find out the queries that are your worst offenders (by time, execution frequency, etc) based on your workload. Because if there is a problem, it should be obvious. 

Then, just look at what they do. Are they doing a ton of SELECT * on wide tables? Did someone decide to store a ton of XML into an NVARCHAR(MAX) column? Run them a few times and use Client Statistics in SSMS to view the actual size of the data returned. These are all well researched and documented areas of best practice that you can communicate are necessary to ensure smooth operation of the database.

But, it may not even be that the data size is hyuuge. It could be just how the client is handling the data (not uncommonly RBAR is at play in this scenario). In these cases, I try to convince the developers to give me read access to their repositories so I can tunnel in and try to do some light reverse-engineering of the code to understand myself what is going on. I haven't had much push back from this since it is an easy ask and doesn't require much of them.

Depending on your language experience, this may be easy or hard, but it definitely can't hurt to start to understand how the ORM and/or code is traversing through the data it receives. From there, if there are any big flashing red lights, you can probably find more resources or patterns to describe the ideal way to handle the data. 

But until you can narrow down the problem more clearly, it isn't surprising no one wants to volunteer their time to help on a wild goose chase. 

It can be hard to get development teams to take the concerns of a DBA seriously, so the more you understand the better. The blame game between developers and DBAs can get tense fast and usually doesn't end up benefiting anyone, so just make sure you're not accidentally making them feel attacked or blamed as the source of a problem. 

Finally - there are other things that can cause this, but they are very rarely the cause in 2018, so be sure to rule those out just in case.