Example: the sysinternals tools for windows were originally distributed as single compiled binaries, and this was far and away the best approach for those tools. Also, just because developers used installers on windows doesn't mean some of them weren't making a boneheaded design decision to do it that way and their app would have been more sensibly distributed as a single binary.

A single, statically-linked binary was (and probably still is, though .NET may be better now) the most portable way to distribute a program on windows. You can't expect perl to be there, you can't expect python or ruby to be there. Java was usually there but not trustworthy. Java version conflicts on windows are a nightmare. That's probably improved unless you're a business running legacy apps. Dlls were difficult to manage and library conflicts were common: http://en.wikipedia.org/wiki/DLL_hell.

Yes, you could use an installer, but that was unnecessary overhead if your application was not sufficiently complex. On windows, you want to be able to say "download this, click on it, and when the gui pops up: have fun."

This is not true on Unix. On unix, a simple perl script is likely to be far more portable than a single binary. Python and ruby are reliable as well. C source code is as portable (or more portable in some cases) than any of the above, though installation is more complex. Also, many of the utilities that would be convenient as downloadable binaries come standard with the OS (grep, find, awk, vi). Unix package managers are powerful and useful, and developers can trust that typical unix users understand them well enough to use them.

Downloading compiled binaries from someone is what you usually do on Mac and Windows.