Because VM is another computer. It runs its own OS with its own networking stack and so on. From the networking standpoint, on the L1 (physical) it is tied to the host, but on the L2 (channel) and all above levels this additional computer is absolutely independent from the "host" one. Just another machine. This is a grey area for containers, because containers actually are the same OS (kernel) as "host". If a container has independent network namespace it will have independent presence on the network, its own loopback and so on, just as a VM. If you imagine a container without a separate netns, that container will be, from the networking standpoint, the same thing as "host" (it will "see and share" host's network interfaces and configuration).
You can't use loopback addresses for VMs for the exactly same reason why you can't use them for another computer: these are loopback, e.g. synonymous with "myself", and each system has its own "self".
Linux's bridge driver is Ethernet bridge. One of the reasons why you can't "bridge" loopback with anything is because loopback is not Ethernet. Actually this is consequence of a reason I gave in previous paragraph.
To avoid any kind of IP clashing you have to plan and account your networks. There is no other way. One particular advice is to never use "common"/"default" networks: 192.168.0.0/24, 192.168.1.0/24 (both are defaults on myriad of SOHO hardware), 192.168.88.0/24 (Mikrotik default), 192.168.112.0/24 (libvirt default, AFAIK), ones that Docker use by default and so on. There are plenty left; use them.
