"Obviously, one doesn't want DH to be the weakest link in the chain. Using AES-256 and only securing the key-exchange with DH-512 is stupid, of course." Exactly. DH and RSA are different, but the most effective algorithm to brute force them is the same (see Tom Leeks's answer), so their security levels are similar. (DH is actually a little bit stronger.) Making your DH parameters and RSA keys the same size is the obvious thing to do.
"Is there any other reason for matching keylengths?" No, but you have every reason already.
"Especially, is there anything to the protocols, that requires this?" No, they don't have to match. You can do whatever you want. TLS doesn't care. Indeed, many websites use 2048-bit RSA keys but unfortunately still use 1024-bit DH. (Apache recently fixed this, finally.)
"If I always use DH-2048 (and everything else is either comparably secure or weaker), would this hurt anything (except maybe performance)?" Well, in a secure configuration, everything else will be comparably secure (RSA) or stronger (AES). If you're using something weaker, you should stop. :-) To answer your question, though, I think it would be fine.
Regarding performance, most clients support ECDHE, which is not much slower than non-PFS key exchange. Classic DHE is significantly slower, and it gets worse as the parameter size increases, but it won't make a big difference if most of your clients don't use it and your SSL terminator isn't running overloaded.
Be aware that some clients -- mostly Java -- are incompatible with DH parameters larger than 1024 bits. If you absolutely need compatibility with them, it might make sense to sacrifice some security and use 1024-bit DH, which is still secure, barely. It would be better to solve the problem another way, though. Newer Java versions support ECDHE, for example.
Edit: The point made by CodesInChaos and Tom Leek, that your RSA key only has to stay secure for a year or two until your certificate expires, and breaking it only allows impersonating you, but that your DH key has to remain secure for decades until you no longer care if your data is decrypted, is very good. It's probably more important than anything I said, so I shall copy and paste it in here. :-D
Edit: By the way, I would caution against exceeding 2048 bits. You'd be entering a realm of less-studied client compatibility issues. Firefox, for example, used to have a limit of around 2200 bits (really). (You could probably ask the GnuTLS community. They have experience with uncommonly large DH.)