As long as the host does not bridge traffic, there is no loop.
bpduguard (Cisco speak, other vendors may have other terminology) are settings usually applied to host ports.
Continued traffic flow is ensured by probably the most fundamental function of a switch: MAC address learning.
Once the host fails over to the (former) standby interface, the ethernet frames it sends out automatically trigger the switches to update their CAM tables, upon arrival of the frame at the given switch port.
Since it is not ensured that all of the host's (unicast) frames reach all switches, there might be some slight delay until all switches have updated their tables. The first broadcast or multicast frame from that host or VM will however be seen by all switches, and since broadcasts do happen every so often, you might never actually notice a delay. However, there can be cases where an admin may run into the "old mac-address-table problem" - just as Darrel Root pointed out.
That's why some hypervisor hosts have a feature called "notify switches" (for example VMware ESXi and its vSwitches). If they reassign a VM to another NIC, e.g. in case of a NIC failover or failback, they will send out a burst of RARP broadcast messages, through the given VM's new uplink, containing each applicable VM's MAC address as source MAC address. All these RARPs are broadcast, so they travel through the entire network (or VLAN), and all switches can update their CAM tables accordingly. ESXi sends these broadcast bursts instantly once it sees "line protocol up", so having
portfast trunk on an ESXi's switch port is essential. Without
portfast [trunk], the 30sec timeout before the switchport port goes into FWD mode will kill all attempts to "notifiy switches". This 30sec delay even exists on non-portfast ports of Rapid-Spanning-Tree environments.