Rotating the group was never the point or the problem. The problem was that typically Linux distributions shipped a 1024-bit hard coded DH parameters file and most people didn't bother to change it.
Groups with low security remain the default for things like IPsec configurations in firewalls and so on, even now.
It's perfectly fine to keep a fixed DH parameter choice. In some senses that's exactly what using ed25519 is. The point is that the strength of the group that results is sufficient to mean that even the NSA with their budget can't break it, even targeting that one curve. It's just that elliptic curves are much more efficient than picking a single 2048-bit or 4096-bit DH group, so why bother with that when we can pick a 256-bit EC group instead?
The nothing up my sleeve part isn't particularly relevant to this. The choice of elliptic curve is quite involved so it doesn't make sense to simply spit out a random field and random curve coefficients. Moreover given the server communicates a prime and a generator for the DH group, the client is quite free to do some primality testing and reject the DH group if it wanted to.
Also, there's a nice body of work showing NUMS can be manipulated. You might be interested in https://bada55.cr.yp.to/
I think you're muddling the concepts a bit here. Nothing up my sleeve isn't the main and only argument that justifies the move to ed25519; the original group wasn't backdoored in the first place. Just potentially within range of the NSA.