It is just something I wonder about…
In OpenGL an object is identified by an integer constant. If you look at that, all glGen* calls seem to be totally useless, it is actually more convenient to me to allocate new “handles” myself.
Is there anything that speaks against it? Will a driver actually “allocate” a handle in a a special way that will benefit performance f I use the glGen* commands?
I can’t tell you what the drivers actually do, but that’s how I would implement it:
For associating the handles with an object, I have to use a hash table. I don’t know anything about the integers I’m going to get, so I’d choose a very simple hash function, propably just a bitmask. Then I’d implement the glGen* functions so they generate zero collisions, to maximise performance.
But as I said, that’s just how I would do it.
That being said, it’s propably better programming style to use the glGen* functions instead of using arbitrary numbers as handles. And with Long Peaks, the integer handles will disappear, so if you plan to port your application to Long Peaks, using glGen* everywhere makes this task a lot easier 
If you look at that, all glGen* calls seem to be totally useless, it is actually more convenient to me to allocate new “handles” myself.
It’s only convenient if you like to explicitly allocate the handles yourself, which requires remembering that, say, “texture handle #4 is the background image.” That way, you won’t “reallocate” the handle later.
I don’t see the point in doing what the driver is perfectly willing to do.
Is there anything that speaks against it?
You mean besides basic code-cleanliness? In regular (C/C++) code, you explicitly allocate an object, use it, and then explicitly delete it. I can understand wanting to remove the explicit deletion (garbage collection), but it’s not like that handle actually does anything until you call glTexImage or glBufferData or whatever on it.
You’re still going to have to construct the contents of the handle, so why not construct the handle itself?
This was an incredibly bone-headed decision from the original OpenGL 1.0.
Zengar:
Ok, that’s a good point. Never thought about it that way, as I never used a third-party GL library, but this is really a good point… Still, a single function like glGenIDs() would suffice.
If you have some kind of object wrapper around your OpenGL objects (e.g. one that auto-destroys the underlying OpenGL object), you can just use the address of the object as the handle.
Of course, this is assuming no 3rd-party OpenGL module and your pointers are the same size as the object handles.