Again, the distinction is only in nomenclature. Much of it is historical (on both sides btw.), Mikrotik and Linux come from a traditionally pure software past, while many other manufacturers come from the hardware forwarding plane aspect. Let me attempt to clarify.
They don't. The bridge is a pure L2 construct. What is a bit confusing for people who are not intimately familiar with the respective parts of the networking stack is that the bridge (the L2 entity) and, the internal CPU port and a routed interface that connects to the "native" VLAN (that is, again a bit confusingly, specified as the bridge's PVID) is called the same. They are only called the same - they are different entities and there is no co-mingling.
On the contrary, what makes this name overloading possible is that it is always clear from the context which meaning we are referring to, because in each context only one makes sense. Whether it was a good idea to name things so... that's a valid question.
For the above reason, it isn't. The port setting (pvid, ingress filtering) and the vlan table directly 1:1 correspond to hardware functionlity.
In the world that Mikrotik chose to implement, it is also very simple. Your case 1: the port is part of a bridge. Case 2: the port is not part of a bridge.
In the first case the port is "consumed" by the bridge, in the second, it can be used as a routed interface.
I think you're onto something here. I don't really think the lack of distinction is the key. Rather, the fact that when you're dealing with a software implementation, you can create arbitrarily complex setups and implement advanced features, and it only costs you a few hundred KB of software. Having all that in silicon is expensive. Of course, speed and efficiency suffer.
One of the areas where I routinely deploy Mikrotiks is in industrial automation networks where bandwidth doesn't really matter, however flexibility and advanced features are necessary.
Again, Mikrotik uses the Marvell implementation natively. (The while modern vlan filtering approach to bridges and its offloading were developed hand-in-hand and funded by Marvell.)
I think it's coming. Really slowly... I think the issue is that VRFs must fit in with the rest of the routing system. And that's a lot of work, of which we're seeing pieces of with each release.
Again, you can see work being done around it.
Most manufacturers push out what the manufacturer SDKs are natively capable of. (And often a product lines will have exactly the feature set of the underlying SDK, with some features or modes of configuration never to be seen again.) Mikrotik's philosophy seems to be to integrate it into their system. This has the benefit that new features can be integrated with the previously established capabilities. Of course this is slow.
It also has to be admitted that the Marvell chips that Mikrotik uses (they're absolutely not top of the line) are infinitely more primitive than e.g. Broadcom's designs, which, again, are dwarfed by the capabilities of Juniper's custom chips.
Where you're absolutely spot on is here:
It should be normalized to have all ports that are connected to the switch chip be configured as part of a single bridge. It is not only possible but very easy to do, and I start out my configurations is this way. It's a way more natural way to look at the hardware as it actually is.
I think here he big obstacle is that people have a hard time getting used to this sort of configuration after seeing the other one for years and it seems unfamiliar. Also, there's a mistaken assumption that "fewer lines" of configuration means simpler, which is clearly very far from being true.
I’m so happy that RouterOS v7 has long-term channel too