1. The "Long Tail" of Compatibility
While Uutils covers the most common use cases perfectly, GNU Coreutils has 30 years of edge-case handling. Uutils is still working to pass the full GNU test suite.
Scripts that rely on obscure, undocumented, or legacy behaviors of GNU tools (like specific cp attribute preservation or complex sort keys) may break when switched to Uutils unexpectedly.
2. Binary Size
Rust binaries are statically linked by default, meaning they include their dependencies. A standard GNU ls might be 150KB (dynamically linked to glibc), whereas a Rust equivalent can be significantly larger.
While Uutils offers a "multicall binary" (like BusyBox) to mitigate this, on extremely constrained embedded systems where every kilobyte counts, C implementations still have the edge.
3. Missing Features (SELinux/ACLs)
Full support for advanced filesystem features like SELinux contexts or complicated Access Control Lists (ACLs) is often more mature in the GNU upstream.
If you are managing a hardened security environment (like Fedora with Enforcing mode), verify that the Rust implementation of ls -Z or cp -a handles contexts exactly as expected.
4. The "Battle-Tested" Argument
GNU Coreutils is the bedrock of Linux. It has been debugged by millions of users for decades. Uutils is an amazing project, but it is newer.
Replacing the foundational userland tools of an OS introduces a risk of "unknown unknowns"—bugs that haven't been discovered yet because the software hasn't seen as much diverse hardware and usage as GNU has.