Been there too. It's normally a PITA to fix, especially if you've got dumb switches and hundreds of drops. STP in the smart switches helps, but can do weird things in other ways.
But you're right, at the end of the day, it happens because somebody plugged two switches together, and until you find that problem, life sucks.

What makes life suck even worse is when you realize it was YOU who plugged the two switches together in a closet with 300 drops in it. hehe. Yeah, I got a plaque for that one. ;)

In a big environment where you have more than 6-10 downlinks to other switches, I usually use the "bisection method" as a trouble-finding algorithm (http://en.wikipedia.org/wiki/Bisection_method).
That is, for example, you disconnect the first half of the network connections you have on the main switch. If the problem persists, you reconnect them (to make the poor, remaining network service to flow again) and disconnect the first half of the second half and so on, recursively. If the problem disappears, reconnect half-at-a-time (recursively) the disconnected cables.

Since in the clip I see you use a specific vendor for your main switch, I can say that using the same switches configured to run multiple spanning-tree, we had good results in detecting and automatically blocking loops till the first level of unmanaged, non-stp switches (with fast intervention times since mstp is faster than stp).

Keep in mind that enabling stp on your network, loops are less likely to block the entire network, but more difficult to come up to your attention since you need good monitoring tools to query your network equipments about stp state for each port.

In a large scale environment, you should be using spanning-tree capable switches in order to prevent L2 loops from bringing down your system.

on the plus-side, that means you have the ability to have a hot-standby cable (like via an alternate path) between your switches, and STP will make sure that only one is in use at any time.