I couldn't disagree more. However, everything depends on what "results you're looking for". That custom shader that outputs the values does just that and often only that. Then the shaders that do lighting are completely separate. Now you have much fewer shaders as well as many more lights. Clever implementations even get more dynamic shadowing (I haven't looked at those much though).
I'd have to disagree that deferred shading is any harder than forward, especially if you've done something like shadow mapping before (ie, you've done more with OpenGL than send a single tri through a VAO). I thought you summarized deferred (in the manner that most would implement) rather succinctly, and of course more research would be needed to implement it.
The lighting shader(s) for deferred are a lot less complicated than the uber-shader or 293485 shaders for various combinations of diffuse texturing (splatting, bump, etc), shadow or not, number of lights on object, etc. Perhaps not just one, but not a "super-shader" when it has a single, easily maintainable task to perform per shader. Separable shader objects help, but I really prefer the clean split.
You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessive with your rendering pipeline.
Curious, filling a few buffers with carefully chosen layouts is hardly obsessive (I apologize for the censorship, but it wasn't relevent to what I was quoting, so I just left it out). In what way to you need to be more controlled? I get needing a forward pass for transparency, but chances are there's not that much of that and you didn't need that many lighting effects from it anyway (or at least I don't which is why I don't mind needing the pass for it).