It strongly depends on your organizational structure and what services your staff is supposed to use.
Everything that syncs back to a cloud (Like Dropbox, iCloud, Google Drive, etc) is a good start to limit - especially as those syncs happen in background, nobody would really notice that the task is taking slightly longer. When using DFS in a distributed Active Directory, that is something that shouldn't be limited.
If you have a guest WiFi network, that could be rate-limited as well.
I usually schedule Queues - limit at daytime, more b/w during off-office-hours, but strictly limited during the windows we sync our backups against AWS.
When using VoIP, reserving a small amount MBps for SIP traffic makes sense.
With all this - always bare in mind that you could turn a good user experience into a really bad one, so don't overdo it.
You ideally enabled interface graphing a long time ago - have a look at your WAN graphs, match it against the bandwidth you booked and then consider again if you really have th eneed to limit.
If your overall link saturation is below 75%, I don't see a reason to limit anything. What is worse? A short period of saturation or a longer period of almost-saturated uplinks?
The sooner a transfer ends, the sooner bandwidth is available to others again.
MTCNA, MTCUME, MTCWE
There are 10 types of people: Those who understand binary and those who don't.
There are two types of people: Those who can extrapolate from incomplete data