Sleep and suspend, outside the white-box laptops, pretty much never worked for me on Windows (2000, XP, 7). That's at least 4 home-built PCs. First one I thought I have messed up with the parts. But for the later ones I have specifically looked for the the parts officially supported by Windows. And still no dice.
On Linux, it is historically hit and miss. On earliest systems, the sleep and suspend were not supported at all. Later, when Linux started warming up to the laptop support, it still generally didn't worked for me (but I also haven't specifically tried the distros which officially claimed to support the suspend). These days, Linux' sleep/suspend support (on Xubuntu) generally works for me without problems.
The last PC I have built, Windows fails to come out of the sleep/suspend. With hybrid suspend it takes ~5 minutes before Windows reverts to resume from hibernate and finally starts. The (X)Ubuntu 12.04 and 14.04 have no problem with the PC whatsoever: both sleep and suspend worked out-of-box without a hitch.
P.S. To the problem with the controllers SteamOS had, I can probably relate. In office I have several custom USB devices and corresponding applications which misbehave after suspend. The applications open the devices and keep them open. After suspend, it seems that Linux tries to "replug" the devices, but the device nodes are locked by the applications. Consequently, the kernel (or udev?) assigns to them new device nodes. Applications do not work, because devices have "disappeared". Restart of application doesn't help because the device nodes are not there. One has to stop the application, unplug the devices, replug the device and start application again. From perspective of the software developer, it is a rather underdeveloped area in Linux: detection and handling in application of coming out of the suspend. On Linux there is precisely zero ways to reliably detect that the system just came out out of the suspend. One has to resort to stupid unreliable hacks like the polling of CLOCK_BOOTTIME.