Because some windowing systems do translucency (alpha), games use translucency (alpha) all the time.

You can not do translucency without some form of alpha value, the A in RGBA/BGRA/ARGB/ABRG.

Another thing is that 32bit is 2^5 and optimizing HW for such numbers is probably easier.

Also I think 32bit for (frame) buffer will be obsolete in a few years. Already most new games use FP16 per channel, in 3-4y FP32 might not be out of question. Thouhh I'm not sure if >=FP16 will be used in regular textures loaded from disk or not, probably not very soon.

If gfx cards had used a HSV colour space we could have gotten away with 16-bit colour modes and textures (i.e. H=4, S=4, V=8). That would have given us a good speed boost for free.

As gnolam said, gfx cards like aligned data. Also extra 8 bits can be used for one additional channel, which can be used to store alpha channel, gloss map, height map or any other single-channel data. This additional channel on the screen can be useful, too, especially during multipass rendering to achieve complex effects on old hardware (eg. per-pixel normalmapped lightning on GeForce 2).

It can. High dynamic range images often use 16 bits per color component giving 48 bits total, sometimes even using 16-bit floating-point numbers. This extra brightness allows to change scene exposure without losing quality. "Overflows" are usually converted to glowing areas during image post-processing, giving everything nicer look, especially on shiny and reflective objects.

You can assume constant alpha or get alpha from different texture.

32-bit framebuffer and texture formats won't be obsolete too soon, as 64-bit or wider pixel formats take considerably more bandwidth, which reduces fill rate. I agree that FP16 for textures won't be used too widely (except for skies) as 8-bit channels are doing well enough and reflectiveness (diffuse or specular) doesn't vary that much over the material to really need FP16 color formats.

Slow blending, texture filtering and pixel shaders would compensate this speed boost, probably making everything even slower.

Hmm. ok. I'll take your word for it. I just remember reading that Jpeg and other image compression routines tend to compress the colourspace normally, so I didn't think the effect would be as noticable as RGB555.

Is that not "some form of alpha value"?

I don't follow, what exactly do you mean? 16 bit color is 565 (RGB) thats 5 bits red, 6 bits green, and 5 bits blue. Or sometimes 5551, 5 red, 5 blue, 5 green, 1 alpha. It's not "shades" its specific colors.

Ah yes, I was thinking of something like this which I found several years ago:
http://r0k.us/graphics/png16.html

This kind of thing really appeals to the amiga loving part of my mind!

Yes, but it's not in RGBA, ARGB, BGRA or ABGR.

Modes like D3DFMT_G8R8_G8B8 will. In this case, each pair of pixels shares two channels and only one channel varies between them (green in this case). It still uses 16 bits per pixel, but gives you entire 24-bit color space (somewhat restricted, but still).

AFAIK V isn't luminance, but value. HSL has luminance and uses slightly different conversion methods.

That's right, it's because the human eye has less spatial resolution in chrominance than in luminance. Even analogue television takes advantage of this by squeezing the colour signal on to the higher bandwidth traditional monochrome (luminence only) signal.