Why is Mozilla recommending predefined DHE groups?

I think the reason for using predefined groups is clearly answered at the page your reference:

Instead of using pre-configured DH groups, or generating their own with "openssl dhparam", operators should use the pre-defined DH groups ffdhe2048, ffdhe3072 or ffdhe4096 recommended by the IETF in RFC 7919. These groups are audited and may be more resistant to attacks than ones randomly generated.

I connection with the Logjam attack it was advised to not use pre-defined DH groups with 1024 bit or lower since this key size is considered in reach of today's attackers and it might be worth the effort for heavily used keys. But larger key sizes are not considered in reach of the attackers yet.

I think the idea behind RFC 7919 was more about interoperability.

While a custom DH group server-side is potentially more secure and will not be affected if e.g. the NSA manages to crack one of the more commonly used groups, it puts sanity-checking effort ON THE CLIENT. And these clients might have wildly different ideas about what constitutes a sane and safe group. They might have different ideas about acceptable bit length for example. And there was no back channel. The client had no way of telling the server in advance "I will accept such and such groups..." and no way afterwards to tell the server "Sorry, I won't work with that group!" The client would just fail and the server never knew. Interoperability nightmare.

Now what RFC7919 tries to do is use the same logic that is already in place for elliptic curve DH and use it for regular ("MODP", "finite field") DH.

That way the client at least gets to say in advance "I will accept such and such groups..." And the handful of groups that make it into the IANA group registry can be checked/vetted by the public.

The RFCs Abstract lists the rationale:

Abstract

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

Update 2017-02-03: Paper

I just found this paper:

• Cryptology ePrint Archive: Report 2016/999: 2016-10-17, Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS

They say in the abstract that clients typically do not check parameters at runtime because of performance hits.

So defining, sanity-checking and naming some finite field DH groups makes sense here. (At least more sense than not verifying at all.)