Would it be that complex to have 2 additional fields in the “Filter Rules” “NAT” sections ???
DateTime when a certain rule was created
DateTime when the last packet “hit” the rule
(probably will impact performance I guess)
Eg. when you create “Address List” there is date-time stamp when the entry was created.
Sure you can reset counters and “wait” until you see increases but…
Sure you can “log” everything so you have a date-time stamp but… 
Interesting functionality but the better question is
a. why do you need it
b. what do you do with it.
If nearly 100% of admins want the same functionality and rate it as a high priority then you have a case!
If 1 admin wants the same functionality and he/she/they etc typically buy 1M plus worth of products, then MT will make the case! 
Well … the products that I use professionally have these things. (eg Palo Alto FW) for many years (Checkpoint is not different)
These are very simple things that might make life of administrators more efficient.
I can’t image a detail like this would require a whole dev-team to crunch on this for weeks…really…
But I agree, probably the whole dev-team is ironing out ROS 7.x issues at full speed, so “enhancements” like this are probably queued all the way at the back
because product A has it, doesnt mean MT should have it.
might make admins life more efficient hardly sounds like a compelling argument for a high priority request 
sounds like it certainly is a caboose change…
“Mikrotik” and “high priority feature requests” are for sure Contradictio in terminis
For now I prefer a more stable 7.x ROS for sure, my new (lab) RB5009 is not doing bad, but I’ve seen erratic CPU usage (> 50%) on 7.2rc1 doing nothing except having a PPPoE open to my ISP
Now back at 7.1.1 which does not suffer from this 