An interesting side effects of disabling DHCP-Snooping is that Fasttrack seems to be working again on my router. Since over 1.5 year my RB5009 has been running in an all-VLAN configuration. All 9 ports are in the main bridge with VLANs used for everything. The WAN port (sfp-sfpplus1) is part of the bridge and is an access port of a dummy VLAN (id 1000), with pppoe-out1 running over that VLAN. All ports have the H flag. @raimondsp from MikroTik wrote about such setups and said that it wastes a few CPU cycles, but not much:
http://forum.mikrotik.com/t/v7-14rc-testing-is-released/173569/146
Everything works (except 1 thing) and the router is fast enough (maxed out my GPON line without problem at > 2.3Gbps download) and I like having all the ports connected to the switch chip managed by the bridge that maps directly to the switch chip, so I have been keeping that configuration for the past year and more.
What no longer worked since switching from sfp-sfpplus1-out-of-bridge to sfp-sfpplus1-in-bridge-as-access-port is that all the fasttrack counters no longer increased above 0. The counters in the dummy dynamic rules (with the special dummy rule to show fasttrack counters comment) all stayed at 0. Same for the fasttrack counters at the bottom of the IP → Settings dialog. But the IPv4 Fasttrack Active checkbox on that Dialog is still checked. Also, most of the connections in the IP → Firewall → Connections table have the F-flag, with fasttrack in the status bar when viewing the details. But on the Statistic tabs of those connections, Orig./Repl. Fasttrack Bytes and Orig./Repl. Fasttrack Packets are always 0. So, I assumed that the special configuration caused some requirements for fasttrack to fail and fasttrack has become effectively useless. It didn’t bother me because performance is still above my needs and the majority of my traffics are IPv6 anyway.
But after turning off DCHP-Snooping in the past couple of days, suddenly the fasttrack counters started showing positive numbers, at tens of GBytes now. And the fasttrack counters on the statistics tab of the individual connections now also have positive values. It looks like turning off DHCP-Snooping also triggered something that causes the fasttrack requirement to be fulfilled. I am not reporting this as a bug, only as an interesting anecdote 
.