Well, it's one less thing for the server to get wrong; I'll be giving my answer in the context of TLS 1.2 (as that was the context Mozilla assumed); remember, in TLS 1.2, it is the server that proposes the group, and Mozilla makes clients.
A "randomly generated group"; there are a number of ways of generating such a group, and they vary both in complexity, and (less obviously) the security. Depending on the algorithm, you could generate a random prime, a "DSA prime"[1], a "Lim-Lee prime" [2], or a safe prime [3]; I have arranged the types of primes in order of both increasing security and increasing cost to generate.
The group includes the generator - how is that selected? Ideally, we want to select a generator with a large prime suborder; does the server do that?
When you use the group, will you ever reuse the private exponent? If you do, well, DSA primes can be weak in that scenario.
So, depending on the algorithm the server uses, the group has variable security characteristics; worse yet, the TLS 1.2 protocol does not give the client enough information to vet the proposed group (it can determine whether the server proposed a safe-prime, but since TLS 1.2 doesn't mandate safe-primes, there's little it can do with that information); in particular, it cannot determine the order of the proposed generator.
Hence, if Mozilla supported server-generated groups, they'd be trusting that random servers did this rather subtle process correctly (without any way for them to verify it). In contrast, the 7919 groups are known to be correctly generated, so that's one less thing they need to depend on.
And, if you're worried about someone computing a factor base, I recommend you switch to ECC groups.
Also, I should list things which were likely not a part of the Mozilla decision:
The possibility that the server could accidentally select an SNFS-friendly group, that is, a group where the Special Number Field Sieve algorithm was applicable (which would allow computation of discrete logs considerably faster than the standard GNFS (aka NFS) algorithm can). However, the probability that a SNFS-friendly group is selected is sufficiently tiny that, in practice, we don't need to worry about it.
The possibility that a malicious server could generate an "easy to solve" group. However, there are lots of other ways a malicious server could foil security (for example, by selecting the private exponent in a guessable way, or just publishing the symmetric encryption keys); we need to assume that the server is honest (and so we need to protect only against accidental errors).
[1]: DSA prime is my terminology of a prime of the form $kq+1$, for $q$ a prime of perhaps 256 bits (and $k$ being an arbitrary even integer of the appropriate size). The point of this is that it generates a group with a subgroup of a known size, and are essentially as cheap to generate as a random prime.
[2]: A Lim-Lee prime is a prime of the form $2qr+1$, for $q, r$ both primes about the size of half of the full prime. The point of this is that it gives you most of the security advantages of safe primes, and are much cheaper to generate.
[3]: A safe prime is a prime of the form $2q+1$, for prime $q$. This is standard and common terminology (compared to the other two); since I did define the other two, I thought I'd define this as well.
