So it seems that l2mtu of a bridge gets set to smallest l2mtu value of all slave interfaces (OP should check the whole list of interfaces, from the screenshot it's not clear if the whole list is shown or it's actually truncated) and can not be set. And it's logical that MTU of bridge is set to smallest MTU value of slave interfaces ... bridge (the switch-like entity, being L2) doesn't perform fragmentation (only L3 device can do that), so bridge interface (which is actually used by router to interact with that L2 domain, it's not used when "only" switching traffic between slave interfaces) should have MTU small enough to pass whole ethernet frame via any of its slave interfaces ... because the egress physical port for a frame gets known only after frame lands on the bridge (the switch-like entity) consulting ARP tables.
Yes, i've posted an exhaustive list of interfaces, that is the first thing i checked and double checked.
Which means that OP's setup with different MTU settings for different interfaces, enslaved to the same bridge, is logically invalid. And it could happen that if all slave interfaces got mtu set to same (jumbo) value, it would be possible to set larger MTU on bridge interface
I've attached another picture, of a CRS305, setup the same way, the reason we do this is that some devices have an MTU limit, but we have plans to swap them later, and rather than changing uplink MTUs in deployment, we set those to their final values.
As said you suggest, technically, we should just set all l2mtu always to 10218, because technically only L3MTU matters as long as l3 MTU is set correctly(and l2 is sufficiently large enough) then the routers will do the fragmenting required to send over the interface. To be honest, i have very little idea why mikrotik ships their products with a default 1600byte l2mtu when they should just give it the max l2MTU always. Most other enterprise switches do this by default. There are some that are stupid and put the l2MTU really low(ubnt edgepoint, netonix).