What's the benefit of using shift (for slow animation) when minimizing windows? I came across this today by accident:
If you try to minimise a window in OS X 10.8 (might be in others) while holding down the shift key the window will very slowly go into the Dock. The whole animation is slowed.

Any ideas what the purpose of this is?
As with @napcae's answer, the "slow motion genie" effect is just a bit of fun, but I have used it in the past to demonstrate (usually to Windows users) some of the finer points of the Mac OS X display subsystems.  Namely, that rather than drawing each window on a pixel by pixel basis (think of Windows systems that leave random stray parts of windows as you drag them around and the window subsystem struggles to keep up with all the redraw mechanisms resulting in scroll bars hanging in mid air, or that nasty windows trail thing), OS X essentially draws a windows contents using something that is more akin to a 3D game engine mapping a texture to a polygon.  You can demonstrate this by having the following command ready in a terminal window, and quickly executing it while you slow-minimise a window:

killall Dock


The dock process is the thing that governs all this sort of thing, and if you kill it it will happily respawn a new one, but the operations that it was part way through completing won't get finished or reversed.  You will end up with a half minimised window that is warped into a strange shape and yet which is still fully usable.  Check it out with textedit, and note that you can still type in it (selecting text is more difficult!), or try it with a Quicktime movie window and notice how the thing is still playing.

Essentially its not just a daft effect, it's demonstrating the window drawing capabilities of the display layer, and how they are managed in a superior way to many other desktop OS window systems.

Note that this effect has been around since at least 2001 (according to a Google search), and I first knew about it in 10.4 where I saw it used to show off the new graphical window manager that used the Quartz Extreme engine to draw the windows.  If I recall the details correctly essentially every windows is basically made up of Quicktime, Open GL or Quartz 2D data source, the latter of which is essentially internally rendered into postscript (essentially all your window dressing elements, toolbars, scroll bars, are a PDF...), which is then rastered into a single window combining all the elements (Your PDF window dressing, with it's quicktime or openGL contents, or a mix there of for a web page etc) as a 3d "texture" on a 2d plane by Quartz Composer to make the window you see.

For more details read the following 2 pages from the Siracusa Tiger Review over at Arstechnica which discusses the way in which the window manager has evolved and has a pretty good explanation of how it works, which is by and large the same now as it was for Tiger (or at least, the changes are not as large since Tiger as they were before Tiger which is when the GPU started to take over pretty much all window drawing tasks from the CPU)