Clients do not "connect" to the router. IP datagrams are forwarded (and NAT'ed) through the router as they are received.
The closest thing to a "connect" is when a client uses DHCP to get an ip address. But that is not a connect, and clients don't really have to do that. And when a client shuts down the router doesn't know it, so there is no "disconnect".
Also, a client could be running but not using the internet except for an occaisional google. Would you want to kill transmission just because somebody is using MSword or Excel all day long?
I guess you could come up with a script that would figure out the bandwidth usage of the lan & wireless (subtracting out the bandwidth generated by transmission within the router) and use that as your trigger. You'd have to do some sort of time-average. This is going to be darned hard to make work, though.
You could use a time-of-day method, where you shut it down during the day and have it only run at night.
I run transmission with "nice", so it runs at low priority. That doesn't directly effect the bandwidth it uses, just the cpu priority.
You might want to configure QOS so that torrents are low priority.
BTW, my experience indicates that it is not transmission's bandwidth usage that's the problem, but the huge memory footprint of transmission-daemon. If your router is a small one like a WL-520GU you are going to have lots of trouble.
Presently I have a 520GU as my primary router but I am running transmission on a RT-N16 that is configured as a client and *not* as a router. No bandwidth problems whatsoever on any of our user's computers.