Why do we use linux bridge?

Of course you don't need a bridge to use VLANs.

But you do, if you want to:

1. "merge" different networks to be treated as a single entity, e.g. eth interface with wlan - like in case of home WiFi router on the LAN side, i.e. connect distinct network segments in L2, i.e. without using routing,
2. build a switch (in fact, every switch actually bridges all the VLANs between their ports) - this is a case of virtualization; if the server was not virtual but physical, you would connect it to the network using the real switch,
3. ease configuration of failovers - it might be better to create "virtual" bridge interface, that is backed up by any physical (or logical! - like VLANs created on physical interfaces) configured at a time, than changing configuration of the underlying interface itself. For example: br-wan might have IP setup and you can simply switch devices below (wlan0, eth1, eth2.45). The bridge might have fixed MAC address, so you only change your access method.
4. create hidden (L2) firewall or QoS schaper (or a sniffer), that is not visible in a packet trace.

Note the special kind of a "bridge" which is bonding/teaming, used for link aggregation, for example LACP, to provide either redundancy or higher bandwidth.

On a bare-metal (non-virtualization) host, there is generally no need to create bridges to add VLAN interfaces.

But on a hypervisor, any network segment is essentially split into two:

• the physical network segment between the outside world and the hypervisor
• the virtual network segment between the host and the VM

Note that there are not two but three things that may communicate with each other: the hypervisor, the VM, and the outside world.

You could use routing on the hypervisor to provide connectivity between the VM(s) and the outside world, but that is inconvenient: you would need to provide at least a DHCP helper for the VMs on the host if you wanted to use DHCP. Some clustering technologies also require all the nodes to be in the same IP segment, so a P2V transition for such a cluster would be awkward if routing was used. And unless your hypervisor is a very big server, the number of VMs it actually runs might be fairly small, so it might require slicing the already-limited IPv4 address space to inefficiently small subnets, or use point-to-point connections.

With bridging, the host and all its VMs can be presented to the outside world in such a way that the network connection of a hypervisor + its VMs is for most practical purposes indistinguishable from the uplink of a switch that has multiple fully separate bare-metal hosts connected to it.

The decision to create a separate bridge for each VLAN instead of one big multi-VLAN-capable bridge is essentially a design/presentation choice: it's probably easier to visualize what is going on when actual configuration of the hypervisor's networking follows closely the "logical" network diagrams, rather than having to maintain separate "virtual logical" and "virtual physical" diagrams for networking inside the hypervisor.

VMware made the decision to call their network bridges vSwitches, or virtual switches. Well, a network switch is fundamentally just a multi-port bridge, so you're welcome to call the bridges on a Linux hypervisor "virtual switches" if you wish.