This is a good question. The dedicated page from OpenSSH only says:
OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.
which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some unsubstantiated weaselling that talks of "recent discoveries". Thus, it is time for some sleuthing.
In the source code of OpenSSH-6.9p1 (Ubuntu 15.10 package), for the key generation tool ssh-keygen, I find this remarkable bit of code:
maxbits = (type == KEY_DSA) ?
OPENSSL_DSA_MAX_MODULUS_BITS : OPENSSL_RSA_MAX_MODULUS_BITS;
if (*bitsp > maxbits)
fatal("key bits exceeds maximum %d", maxbits);
if (type == KEY_DSA && *bitsp != 1024)
fatal("DSA keys must be 1024 bits");
The OPENSSL_DSA_MAX_MODULUS_BITS is a constant from OpenSSL's headers, that define it to 10000. So the first four lines check that the requested key size, at generation time, can actually be handled by the key generation process. However, the next two lines basically say: "regardless of the test above, if the key is DSA and the size is not 1024, niet."
These 6 lines are, in themselves, a sure sign that whoever developed that code did not completely agree with himself with regards to key sizes. This code was probably assembled incrementally and possibly by different people. The source of the "1024" can be traced to the actual DSA standard (called "DSS" as "Digital Signature Standard"), FIPS 186-4. That standard was revised several times. In its first version, DSA was mandated to use a modulus whose size was between 512 and 1024 bits (and should be a multiple of 64, presumably to simplify the task for implementers). A later version acknowledged the increases in technological power and mathematical advances, and banned any size other than 1024 bits. The modern version of FIPS 186 (the fourth revision, as of early 2016) allows the modulus to have size 1024, 2048 or 3072 bits.
It can thus be surmised that ssh-keygen refuses to use a modulus size different from 1024 bits because someone, at some point, read the then-current FIPS 186 version that mandated exactly that, and nobody bothered to update ssh-keygen when the FIPS standard was amended. Regardless of how this spectacular piece of programming schizophrenia came to be, the raw result is that most if not all SSH keys of type DSA in use today rely on a 1024-bit modulus.
The next piece of the puzzle is the Logjam attack. Logjam is basically about noticing that when a client and server agree to use weak crypto, they can be attacked. This is an attack on SSL/TLS, not SSH. However, the Logjam article does not stop at (rightfully) bashing SSL/TLS implementations for using a 512-bit modulus for DH; it also dedicates some talking space to "state-level adversaries". That part mostly says something which was already known, i.e. that breaking discrete logarithm modulo a 1024-bit modulus (something which would allow breaking both DH and DSA) is right now horrifyingly expensive, but not impossible with regards to our current knowledge of the problem and available technology (similar to breaking RSA-1024, and quite unlike breaking a 2048-bit DH or DSA, which are beyond the feasible with current Earth resources).
To receptive ears, this all sounded like "OMG we are all pirated by the NSA !" and the publicity around the Logjam issue (which is very real) trailed in its wake a substantial amount of hysteria on the subject of 1024-bit DSA keys, included when they are used in SSH.
An extra point was that using DSA requires generating, for each signature, a new random value, and the quality of the generation of that value is of paramount importance. Some implementations have failed spectacularly, leading to private key leakage (notably for some "Bitcoin wallets"). This characteristic of DSA is shared with its elliptic-curve version ECDSA. It can be fixed. But it instilled the idea that DSA signatures can be tricky to do properly (and ECDSA signatures equally, but elliptic curves are cool and nobody wants to ban them).
These parameters, taken all together, explain the ban. This can be viewed as a case of OpenSSH developers being proactive in their notion of security and are ready to force users to use strong crypto. Another way of seeing the very same sequence of decisions is that OpenSSH developers blundered badly at some point because of some poor reading of FIPS 186, and then sought to cover it in the equivalent of dumping at sea the corpse of the inconvenient husband.
Note that breaking your DSA key would allow the attacker to impersonate you, but not to decrypt recorded sessions. While it can be said that switching to an ECDSA key would be a good idea at some point (it saves a bit of bandwidth and CPU), there is no cryptanalytic urgency to do so. You will still have to do it, because otherwise you may be locked out of your servers because some packager was too zealous in the deprecation policy.
