I would think that these limits would prevent you from relaying unconfirmed TXs as your node would spend much of it's time downloading recently found blocks (if the average block is close to the limit).
It seems to prioritize bandwidth for this, or it's just that unconfirmed Txs are so relatively small in size, it's not an issue, but this is how I've run Core in the past. Since, they've upgraded a cell tower nearby, so I let it upload without limits unless I'm doing something where I need a bigger share of the 40kb/s up I can snag. NetLimiter's supposedly adding a feature to give programs bandwidth minimum grants, which'd be great since I could let Core run in the background and then give minimums to web browser (as is, it semi-frequently causes timeouts since Core likes to suck everything down unless it's explicitly restricted, with an odd exception to these timeouts being this forum, I'd guess due to an unusual configuration I'd be interested in learning about).
I wouldn't recommend these kinds of limits for a service using the daemon frequently, of course, but for personal use, it's been a great configuration when I've needed it, and also permits those on harshly capped plans to have the advanced functionality a full node client provides since the majority of post-sync bandwidth Core and other full clients use is not strictly necessary.
