Your inferences are correct; in fact, they are more often expressed the other way round: while each instance (TLS handshake) uses its own group, it is possible to reuse the same group between instances, regardless of whether they are for the same server or a distinct server. All the Logjam business was about clients and servers using a weak group (because the modulus was too short); the reuse of that group by many servers merely extended the scope of the attack.
There is no relation whatsoever between the group and the certificate or domain; group parameters are sent by the server for each handshake, so that clients do not need to remember anything about that group -- and, in practice, clients do not try to remember anything about the group, so they won't do anything special if a given group is reused or not reused.
However, one must take into account that group generation is kinda expensive. It is not necessarily as long as what OpenSSL does, because OpenSSL insists on using a "safe prime", which is overkill here (and, arguably, not "safer" in any way than a non-safe prime, because the terminology is merely traditional). Yet, producing a new group is still a matter of a few seconds of CPU, so you do not want to do that for each incoming connection. What could be done is generating fresh DH parameters upon server start -- thus, the parameters would not have to be saved in any file.
Pragmatically, existing Web servers (say, Apache) can read parameters from a file, and the guide you link to advocates generating a DH group unique to your server. The main value in generating your own group is that it allows you to generate a strong group, i.e. with a large enough modulus. That the group is not shared by other servers is only of secondary importance.
Note that for elliptic curves, everybody works with the same group (i.e. the same curve), because deployed implementations are specialized for that specific curve(*) and cannot handle any other. If group reuse was really an issue, then elliptic curves would have to be deactivated ASAP. Fortunately, reuse is not a problem.
(*) Actually two curves, NIST's P-256 and P-384, which are part of NSA Suite B; for some reason, this suite is increasingly taken by browser vendors as some kind of Gospel, to be followed to the letter, otherwise the gods will strike you with lightning.