First of all I don't think it's a general recommendation to use explicit binding via glBindAttribLocation instead of glGetAttribLocation. That being said, these are the main reasons I stopped using glGetAttribLocation:
First of all, this can cause unnecessary overhead. It all seems nice and well that you can use a readable names instead of numbers. 'What the heck is attribute 7' vs 'oh right, attribute texture_coordinate': I'll explain first what the possible overhead can be and then why that last part doesn't even make sense.
If you need the attribute location often, the overhead of calling glGetAttribLocation can become non-negligible, depending on the driver. So to handle the general case you have to build a caching-system. Great, there goes my easy and readable method with names instead of numbers, I just had to write quite a lot of non-trivial wrapper code. Worse, you should really take care that you destroy the cache when the program becomes invalid, it's quite likely you'll do this wrong and end up with bugs. So we went from 'nice readable names' to 'horrible buggy mess'.
Even more, the 'nice readable names' argument is flawed. You can perfectly do something like the following for locations defined in the shader itself:
const GLint vertex_loc_att = 0;
const GLint texture_coord_att = 1;
...
Or you can also use an associative container like this:
attribute_locations["vertex_location"] = 0;
attribute_locations["texture_coordinate"] = 1;
...
This one you can also combine with glBindAttribLocation, just do this prior to linking:
foreach name, location in attribute_locations
{
glBindAttribLocation(program_id, location, name);
}
Still very readable, no dynamic cache necessary, just some static variables that even might get optimized away.
Then, you say it yourself: it obviously has it advantages when using multiple programs, I won't repeat it here, because Kos explained that one in detail already. I'll just answer one of your arguments:
Attributes that don't need sharing: This implies there are also attributes that need sharing, for which it is a big advantage that you use fixed locations. Why would you mix two location management approaches in one application? Keep yourself from a maintenance headache and stick with one, here obviously the predefined locations because you need them for the shared attributes.
