Ingenu: I don''t think so. Try to avoid small textures (smaller than 128x128), they''ll just increase the number of state changes.
Used a big texture instead (512x512 or 1024x1024), and copy all your small textures to it. Address them through modified uv coords. That is *alot* faster, esp. if you have countless small textures.

STOP STOP STOP all these questions on what is fastest. A state change may be and in general is slow. However, you should profile your code path. Have a seperate path for 1) Changing texture with glBindtexture() and 2) your routine to modify texture coordinates on the fly. For all we know in 6 months time the state changes on the new whizz-bang graphic card will be less of a hit than the texcoord routines. Once you determine what is fastest, then use that path. You could enable a test at runtime to determine the best option for whatever the current pc spec is.

if you use gluloadbitmap() you can use any size image and the glu routine will scale it to the closet ^2 this is maybe why your friend accidently can load any size image as his texure.

Using the texcoord manipulation thing is ALWAYS faster, independend of state change speed. You obviously will need texcoords for texture mapping your object, if you use state changes or not. Pre-adjusting them will get you rid of the state changes, and will NOT modify your runtime code otherwise, there is NO other performance hit associated with them ! You will always gain speed. This works only with non-tiled textures though.