4,096 is already an abundance of caution. You might as well say people should go to 32,768 just to be sure. Then somebody else would come along and say, "why not 65,536?"
Indeed. Mostly, it's just a question of whether or not the software will support a key of such size. Typically, I would recommend that, unless you've a good reason to use a smaller key (like support concerns), one should use the biggest key one possibly can use at the time the key is generated. Though, if one is doing key rotation as one should be, one can always adjust up as needed as time goes on.
Not really, especially in the context of RSA keys, because:
1. RSA is a slow algorithm and gets slower as you increase the key size.
2. Increasing the key size gets diminishing returns on the security margin. Given the performance and compatibility issues, the relatively minor improvement in security once you go beyond a certain key size is not worth it (you should switch to a better algorithm instead).
3. Anything over 4096 (possibly anything over 3072) is overkill anyway - if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely.
I think the general consensus was not extending RSA key size, but using elliptic curves instead? (But NIST and Brainpool curves aren't completely trustworthy and Curve25519 is not yet standardized for OpenPGP, so we're practically stuck with RSA at the moment)
"8192 bit keys are horrible insane from all POVs: There is no extra security because the security is based on the weakest link and this is definitely not the length of the RSA modulus, they make encryption really slow and thereby reducing the likeliness of widespread encryption use, they only help spreading FUD about the security of the RSA or other algorithms."