Sounds like unfortunate phrasing...full disclosure, I was in support 11 years, a technical lead for Enterprise Teams for 6.
Service data is NEVER too large. Taken straight up, that's incorrect. However, there may be optimization to be done. For instance, there may be scale dependences to be set or feature generalization that will help.
For instance, it's pretty frequent for users to attempt to draw every point and vertex at a small scale. Like, it doesn't make sense to show every vertex in a complicated geometry at a state level scale, nor would you want to attempt to visualize every house as a single point. Unless the map is cached, that'll cause real performance issues as all that geometry is sent from the server to the client. That's especially true with editable layers. I'd use scale dependent rendering and symbolize for heat maps and generalize those vertices. I also tend to separate my maps into thematic layers instead of one big uber service and mash them together client side. I find that more scalable for maintenance and helps rendering speed (one godzilla feature won't slow your whole app down). At larger scales you can get more granular. A broad statement like "you have too much data" is patently incorrect. I have highly performant customers with terabytes of data I speak to regularly.
