I wouldn’t put in so definite words as @lfoerster did … because it is possible to use bridge interface directly … the problem is that needed configuration to make things work correctly is in other places than it’s for the rest of bridge ports.
In ROS (and Linux in general for that matter), L3 can only work over untagged (logical or physical) interfaces. So for tagged traffic, one needs vlan interface (from /intreface vlan) anchored to a tagged interface. So most IP addresses on inter-VLAN router will be set on vlan interfaces.
We all know, that we can have untagged port (e.g. etherX) configured as access port for certain VLAN … which is defined by setting property pvid= on /interface bridge port elements.
The complication comes from the fact that bridge has two personalities (this explanation lists even more, but personally I see two principal ones): 1) switch-like entity moving frames between member ports and 2) interface which allows ROS software to interact with traffic passing brdige switch-like entity. The entity #2 is created implicitly for every bridge we create. And most properties are configured in /interface bridge, even properties which logically belong to interface entity. Examples of such properties are: mtu, admin-mac, pvid, frame-types, ingress-filtering, etc. (in the same configuration stanza, we define a few properties which clearly belong to switch-like entity, such as protocol-mode, priority, igmp-snooping, ether-type, vlan-filtering, etc.).
Let me re-emphasize it: quite a few settings of items in /interface bridge are not affecting bridges as switch-like entity, they are not default settings for member ports, those settings are about bridge interface only.
And then there’s /interface bridge vlan which has to properly reference the bridge interface in tagged= and untagged= properties in exactly the same manner as other bridge ports.
Lastly, MT default configuration sets all bridge ports (bridge interface included) with pvid=1 … which, without further configuration change, makes bridge interface member of untagged LAN (as configured or rather not-configured for the rest of bridge ports, e.g. etherX).
I guess it’s the confusion about the multi-personality of bridge that makes many people think that bridge interface should never be used as untagged interface after vlan-filtering is enabled.
And the time to negate myself: I always advise to use bridge interface as fully tagged interface … just because it makes life easier because all the config is then uniformly done. Personally I follow my own advice 