Eh, I don't see the issue here. The MIT license is fine for a few reasons:
attractive to lots of FOSS projects, like BSDs, Redox, etc
no incentive to embed into proprietary projects - ls, cp, etc aren't particularly interesting to embed, and functionality is usually better in the stdlib of whatever language you're using
increases appeal generally for research purposes
I really don't see much benefit of GPL here. It makes sense for larger works with interesting snippets of code, but not for small, one-off tools like this.
Using MIT license means the developers cannot look at GNU source code when writing code for uutils. This feels like a unnecessary hurdle given that uutils wants to be 100% compatible with GNU tools.
This means that we cannot accept any changes based on the GNU source code.
You are totally allowed to look at it. For example if there was some weird behaviour that you couldn't work out, you could look at the GNU code to understand it.
What you can't do is closely base your code on the GNU code. I.e. you can't just translate it from C into Rust.
On the other hand a new GPL licensed version of coreutils will run into the exact same adoption problems that brought us the current mess of "you can use this parameter on GNU but not on the BSD version",...
That's not accurate. They can look at it, but they can't port it. But looking at how it works and then coming up with their own implementation is fine.
The original CoreUtils have beenvetted through decades of use. They have been broken and fixed many times, and they have been hardened against so many edge cases, it's not funny anymore. That's where those 600 tests come from (mostly). Once they have brought the Rust tools to that level, how much performance advantage will there be left?