Let’s look at #1:
Considering every object might have its own material, it involves a lot of glUseProgram calls.
This isn’t that big of a deal, really. Swapping programs is hard, but you’d be swapping textures too, so it’s not like you’re not already changing important state.
Implies the creation of a lot of shaderprogram objects.
This is going to hurt. Indeed, the main problem with #1 is the explosive combination of shaders. While ARB_separate_program_objects will help, it still means you have to write a lot of shaders, or come up with a way to not write a lot of shaders.
Or you can use deferred rendering, which helps to mitigate this. Among its many advantages is that it separates the generation of the material data from the computations that transform this material data into light reflectance (colors). Because of that, you have far fewer shaders to work with. You have a set of shaders that produces material data, and a set that uses the material data to do lighting computations.
So I would say to use #1 with deferred rendering.