Sadly what @Sob writes is true: MT devs stopped at implementing HW offload for CRS3xx, other devices with capable switch chips didn't get that treatment.
The positive thing about bridge vlan-filtering is unified configuration on any RB device. When doing stuff on switch chip, one has to study particularities and set things up accordingly. Meaning that config is even less portable than it normally is. Those particularities include feature-set supported (number of VLANs, support for hybrid ports, support for VLAN in general, ...) and concrete commands used to set things up. In addition to that, there are devices which feature (on paper) decent switch chip, but it may be buggy without ETA on fixing it (Atheros8327 in RBD52G) ... probably that's out of MT devs hands ... and bugs in ROS are easier to fix (most of the time).
So I'd say that most of users (@anav included
) should be using the bridge vlan-filtering because it is, as @Sob wrote, easier to understand (that's relative, some don't get the concept after years of looking at it
) and the same for all devices. Only when this approach becomes a bottleneck, one should switch over to using switch-chip based VLANs.