In a nutshell, and just speaking about the clients represented in ssllabs.com tests (there are probably other similar corner cases with old/unpopular platforms), there are 3 cases where we don't currently offer Forward Secrecy, but we could in theory by enabling a single DHE ciphersuite option and generating a dhparam file for nginx: Android 2.x, Java6, and OpenSSL 0.9.8.
Android 2.x is obviously the biggest reason, but there are probably (sadly) a fair amount of tools out there using older Java and OpenSSL that connect to us as well. In all 3 cases, the ciphersuite change for them would be to switch from TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) to TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33).
The primary issue here is that while we'd prefer to generate a decently-sized dhparam with, say, a prime size of 2048 or greater, anything larger than 1024 will break Java6 clients (and again, probably other corner cases we don't commonly think about), because it lacks support for larger dhparam. We can only specify a single dhparam to use for this, so it limits the other cases like Android to 1024 as well.
The open question in my mind is whether FS at the "dhparam 1024" level notably weakens crypto versus the straight RSA-2048 we're using with these clients today, enough that it's not worth the (strong) benefit of Forward Secrecy. There are two decent StackExchange questions on this: http://security.stackexchange.com/questions/42812/1024-bit-dhe-vs-2048-bit-rsa and http://security.stackexchange.com/questions/35471/is-there-any-particular-reason-to-use-diffie-hellman-over-rsa-for-key-exchange/35521 . Based on who's saying what in those threads, I'm inclined to go forward with the dhparam-1024 option here, adding only DHE-RSA-AES128-SHA to our ciphersuite list (just after our primary set of ECDHE FS-enabled ciphers, and before all of the non-FS options).
Since the issues in those StackExchange links are complex, I thought I'd ask here for any further opinions first.