The current behavior of switching windows when scrolling on the window-list applet is inconsistent with the way the scroll wheel works anywhere else that I am aware of.

Usually the scroll wheel moves the area under the mouse cursor, which is its original purpose and the most likely expected behavior. In some cases (e.g. spinbuttons, volume controls) it changes the value in small increments.
In both of these cases a gradual change is made to the widget under the cursor, which can be easily undone by scrolling the same amount in the opposite direction.

In the case of window-list applet, scrolling switches between buttons that may be far away from where the cursor is pointing. At the same time it pops up the windows belonging to these buttons, drawing attention away from what's happening in the list. 
Even worse, scrolling in the opposite direction does not undo the first scrolling action; while it does switch back through the windows it brought up, their z-order is messed up, and windows that were iconified before will not be restored to that state.

This behavior is quite confusing to users who do not expect it, especially when the scrolling happens accidentally. Furthermore a single movement of the scroll wheel often sends more than one event, thus a single input action that usually results in a smooth and obvious change in the element being pointed at can easily lead to a flurry of windows popping up seemingly out of nowhere.

Other information:
I realize this was implemented as a feature in bug 309956 but i couldn't find any real discussion regarding usability there.

There's also bug 402528 which is asking for this behavior to be optional because there's a problem with some scroll-enabled touchpads starting a scrolling action accidentally, but that seems to be more of a problem with the way "scroll wheel" functionality is implemented in those input devices.

The window-selector applet also switches windows on scroll events, but in that case it is to be expected, because that applet works like a dropdown-list/combobox. By the same argument it might be sensible to switch between the windows grouped into a single button in window-list when scrolling on that button. Personally, I think that even in those cases it might be better not to have windows pop up from a simple scrolling action, but at least it's consistent with the way the scroll wheel works elsewhere.