Within this setup why do we need an additional bridge per vlan? Isn't it enough to add the vlan interfaces as slaves to the main bridge?
It's really about the first sentence in my post which you chose to omit from the quote: if for some reason you can't/don't want to run bridge as VLAN-aware entity, then the setup I explained might be the only possibility.
In this kind of setup multiple bridges are necessary because it's necessary to "bridge" two ports: untagged end of vlan interface and wifi interface. And bridge does that.
And just for clarification, I currently run this type of configuration, but where's the difference compared to having one non-vlan-aware bridge and sevaral vlan interfaces on that bridge?
Non-vlan-aware bridge is ... well, not vlan aware, so e.g. it doesn't manipulate with VLAN tags. But will happily pass frames which have VLAN tags attached. If there's a need to manipulate them but neither hardware itself (e.g. switch chip) nor driver (e.g. legacy wireless driver) does that, then we can resort to using vlan interfaces and bridges. How to pipeline things together depends on what needs to be done (e.g. VLAN tags added on the way between wifi interface and main bridge).
In your example, where bridge is VLAN aware, it's this config that manipulates the tags:
/interface bridge port
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiWIRELESS pvid=40
If bridge was not VLAN aware, then config which performs the same, is this:
/interface bridge
add bridge=brVLAN40
/interface vlan
add name=brLAN40 interface=brLAN vlan-id=40
/interface bridge port
add bridge=brVLAN40 interface=brLAN40
add bridge=brVLAN40 interface=wifiWIRELESS
(the code above replaces single line mentioned earlier)
So there's a new bridge brVLAN40 which actually passes untagged frames, in example above only between wifi interface and untagged end of vlan interface. Then vlan interface manipulates VLAN tags so that main bridge (spanning e.g. ether ports) actually passes tagged frames (without bridge being aware of that). On ether ports side it's then possible to configure VLANs (per port) in switch chip sections.
If there are several ports with same pvid set, then in the "convoluted" config they are simply added to bridge created to carry traffic of that VLAN.
As I wrote before the whole ordeal depends on a) ability for bridge to offload things to hardware (if it can, then by all means avoid doing things the way I explained above) and b) portion of traffic passing between wired ports (if volume is low, then don't do it this way, use vlan-aware bridge). When I did a quick test, hAP ac2 (which doesn't allow offload of VLAN functions from bridge to switch chip) could bridge between two ether ports at wire speed and CPU load was around 50% (so I gather it could do another pair of ports wirespeed, hard limit is 2Gbps interconnect between CPU and switch chip) with CPU resources to run decent wireless at the same time. cAP is even less problematic since it's only got two ether ports. But if device has much weaker CPU, slower interconnect and slower wireless (e.g. RB951G), then the method I'm describing might allow much better overall device performance (it's not necessary to fuss around if device runs legacy wireless as it supports manipulations of VLAN tags, so my RB951G devices don't run the ugly setup).