Yes, these cycles are cpu cycles as measured by the TSC (time stamp counter) on the cpu. Before evaluating the rule we read the TSC and then read it again at completion of the rule and add the delta to the average.
To convert the number into something more meaningful, you will need to know the clock rate of your cpu. You can generally find this out by doing a 'cat /proc/cpuinfo'.
So, in an example, if you are running on a 5100 which uses a 1.266 GHZ cpu, you could measure the latency the rule incurs by dividing 3959 by 1266000000 which yields .000003127 sec or 3.127 usec.
Perhaps a more useful way to look at it is in cpu percentage. If you can estimate the number of times this rule runs per second (you should be able to deduce this number from the number of connections per second on that virtual), then you could calculate the amount of cpu percentage spent on the rule with the following formula: avg cycles * number of rule evaluations per sec / cpu clock rate. So, in your example, let's say you were running ~ 100 rule evaluations per second, then your rule would be using: 3959 * 100 / 1266000000 = .03127 % of the cpu per sec.
I realize this probably still isn't the most useful statistic to give to management, other than to demonstrate that rules for the most part are not really impacting your performance much. The rationale behind providing this number was more for an optimization purpose so you could attempt to improve your rule and then measure the improvement or degradation. For example, time the difference between using "contains" vs. "matches_regex" and you'll see quite a difference in the numbers.
Hope this has been helpful.