The whole argument against deferred lighting is increased render-pipe complexity. That somehow, an extra geometry draw pass is somehow a major problem - but it's not that hard. It doesn't really add a lot of complexity at all - at least not from my view. But then, I designed the batching system to deal with multiple passes draw (regardless of what those passes are).
It's not that is a major problem, or even difficult to implement. It's that it's an extra degree of complexity that doesn't bring a feature list that necessarily justifies it.
There's another issue regarding vertex transform load - but you can get around this by a caching vertex transforms before hand, using stream out or just using effective LOD. The only issue is where you're using geometry interpolation, and that's definitely where shading wins out over lighting on vertex bandwidth.
Stream Out is not on the table for standard rendering. I'm trying to avoid using features specific to the newer APIs in the core rendering code. This is my main reason for not doing a variation on Forward+. Also, I admittedly don't know a great deal about how the actual GPU works, but isn't there generally more ALU available than memory bandwidth? Making stream out not necessarily a great choice in that case.
I'll add that in an engine where you want to offer custom material types, having to use a different lighting technique for them is undesirable. It's not something that I would want to use. The whole idea is to use a unified lighting model, but if you resort to forward rendering when there's a lot of use of custom material types - why bother at all?
Maybe I'm just being too picky here.
This may be a misunderstanding on my behalf, or yours, but forward is used for special materials, not exclusively for "custom materials". When it's done, you'll be able to use the material editor in a similar fashion to UE4. A standard material will output to the deferred pipeline. With this standard material you can completely customize what's output to the G-Buffer just like in UE4. You would only utilize forward for special materials like translucent, transparency etc. This places the vast majority of objects in the deferred pipeline. Forward is reserved for only when needed. For mobile/limited platforms I imagine I'll eventually offer the ability to switch entirely to Forward, but I'm not gonna worry too much about that now.
Perhaps we're approaching this discussion wrong. The technical differences between them do not reveal a clear winner. The performance differences are often negligible on modern platforms. Perhaps the better question to ask would be "what is it you're trying to do that would require deferred lighting but not work in deferred shading?"