(1) I'm curious whether the following 10 different DH Groups are the only groups that TLS 1.3 supports,
Yes, in the sense that TLS 1.3 only allows groups that are explicitly declared as supported in 1.3. This currently includes not only the groups from RFC 8446, but possibly more recent RFC as well, such as Brainpool curves from RFC 8734.
The TLS supported groups registry lists all the groups, but unfortunately it doesn't distinguish between protocol versions (you have to chase this information down in the RFC given as references). The “recommended” column is specifically about TLS 1.3, but it is neither a minimum supported set nor a maximum safe set (you can have good interoperability even without the full “recommended” set, and the non-recommended set includes both acceptable things such as FFDH and bad things such as 160-bit elliptic curves).
(2) and as such, are they the only ones that we should be using?
You certainly shouldn't be using other groups in TLS 1.3 since they wouldn't comply with the protocol. Your software isn't likely to support other groups in TLS 1.3 anyway.
(2) To elaborate on my second query: Given that TLS 1.3 was developed over years by experts, and that it only supports certain cypher mechanisms - can we take that to mean that these are the only mechanisms that should be used?
No: it's ok to use other mechanisms in older versions of the protocol. Not every mechanism that is safe to use made it into TLS 1.3. Some mechanisms that are safe but don't have any practical advantage (faster, smaller code, smaller message size, etc.) didn't make it into TLS 1.3. One of the goals of TLS 1.3 was to reduce the complexity of the protocol, which means fewer choices.
With TLS ≤1.2, you need to balance security (as in: risk of implementation bugs, known protocol weaknesses, or yet undiscovered protocol weaknesses) with interoperability. (This is true with TLS 1.3 as well, but 1.3 hasn't been along for long enough to have interoperability problems when it goes through at all.) Due to the number of existing options and the diversity of the existing software, there's no single right answer for where to put the balance.
Some discussion into what curves should be used has already taken place here, which mentions that secp256r1 and secp384r1 are best.
That discussion was in the context of TLS 1.2, which didn't support the same curves. There's no reason to reject any of the curves supported in TLS 1.3 except maybe secp521r1, which is susceptible to implementation weaknesses. (As the name hints, secp521r1 involves 521-bit numbers – and yes, it's 521 and not 512. Because this is slightly larger than a multiple of 64, there's a non-negligible chance that certain intermediate numbers will have the most significant word be 0, and insufficiently protected implementations might leak that fact when the number is multiplied because the multiplication will be slightly faster. This leak can be enough to allow an attacker to reconstruct the private key with a moderate number of connection attempts.) Curve25519 is perfectly fine and arguably preferable to secp curves because it's easier to implement securely. Back in 2015 it was not commonly supported in TLS, but in 2021 it's a standard part of TLS 1.3. Curve448 is slower and has no particular advantage (barring yet unkown weaknesses in other curves), but it's ok to use it.
For finite-field Diffie Hellman, don't use groups smaller than 2048 bits. Older versions of TLS allow custom groups, and there's no consensus on whether to make use of that. On the one hand, using standard groups might allow an attacker with sufficient computing power (read: NSA) to precompute a very large number of values which then makes attacks feasible. On the other hand, generating good custom groups is slow and hard, and doing that risks creating vulnerabilities that are easier to exploit, such as letting a man-in-the-middle persuade the participants to use a weak group. This is why TLS 1.3 mandates the use of known good groups.