TLS 1.2 was defined in RFC 5246. That RFC does mention the use of MD5 as a possible hash algorithm and does not explicitly forbid it. However, that RFC has been updated by RFC 8446, which specifies TLS 1.3. That RFC modifies the requirements of TLS 1.2 and says the following of the SignatureScheme extension:
Some legacy pairs are left unallocated. These algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or negotiated by any implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used.
It is therefore completely forbidden to use MD5 for a signature in either TLS 1.2 or TLS 1.3, and the IANA has removed these algorithms from the specified list, so they are no longer part of TLS. As a result, the server can't send certificates that use MD5 because “all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in [the client's negotiated] extension” and we've just established that MD5 is no longer valid in this extension.
It is also forbidden to use MD5 by the CA/Browser Forum, which regulates the Web PKI, although that doesn't prevent internal CAs from using it. In any event, responsible parties are not using MD5 for any purpose.
The part you mentioned from the RFC is a little different. In TLS 1.0 and 1.1, the PRF (pseudo-random function) used to generate session keys from the negotiated secret used a combination of MD5 and SHA-1. This use was not insecure, but it ended up causing practical problems for cryptographic proofs of the security of the function, and in any event, nobody wanted to keep using MD5 and SHA-1. As a result, the PRF was switched to use a single hash algorithm, which is much easier to reason about and model cryptographically, and avoids obsolete algorithms in favor or SHA-256 (or, in some cases, SHA-384).
