According to the second draft of the TLS 1.3 specification, custom DH groups have been deprecated. As we all know, hardcoded DH groups are vulnerable to a precomputation attack that allows retroactive decryption. Since TLS 1.3 doesn't deprecate DH for key exchange entirely, I imagine this means it will fall back to the standard groups (e.g. Oakley groups). With this in mind, why does TLS 1.3 deprecate custom DH groups? Why not do the opposite and deprecate standard groups instead, or even deprecate all DH key exchange to make way for ECC?
With TLS 1.2 the server first needed to tell the client within the ServerKeyExchange message about the parameters of the DHE group it supports. Only then the client could act on these. With TLS 1.3 the client chooses instead from a set of named groups from start. Since the client now chooses the groups instead of the server the key exchange can start immediately (all information are known from start) which cuts a full RTT from the handshake, resulting in better performance.
Of course, in theory one could also still have custom groups this way, only that the client defines these groups this time and not the server. I cannot find any specific information why custom groups where removed but it seemed to happen during some interim meeting in mid 2014 based on this message in the TLS mailing list. I cannot find any information about this on the official meeting in 03/2014 nor on the next one in 07/2014.
But, some information in the paper Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS from 2016 might point into the right direction. This paper discusses deniable backdoors using custom DH groups and in VII. Discussion A. Mitigation Strategies various strategies are discussed to prevent such backdoors, like disabling DHE completely or using only known good (named) DH groups similar to what is done with ECC. If fully removing DHE is not an option then having a fixed set of named DHE parameters looks like the easiest way to handle this problem.