This is the single worst aspect of Rust. Can this be fixed in say in a 2021 or later edition?
It is very unlikely, though, given that means there are already two slight variants. Introducing another has a very high cost.
It is normal to have a set of tools that you like or wish to retain. There may be a package installer (rpm, apt, msi, etc.), a build system (plain Makefile, autoconf, CMake, the Visual Studio project/solution files, etc.), a linker (link.exe, the old binutils ld, gold linker, etc.) and so on.
Most of us aren't looking to replace any of that. Even if we are, the stuff coming along with Rust is probably not what we are looking for.
Cargo is thus, to many of us, an unwelcome surprise.
I come from Python, and it would be ridiculous if I said "well we already have Poetry so why doesn't Rust just use that". I don't think saying the same thing about the C++ tooling is different.
Rust is a natively-compiled systems language that supports the C language ABI.
Python, Perl, Java, Lua, Ruby, Scheme, and other such things are expected to bring along some extra gunk. I'm not saying that this is good, but at least it is unsurprising.
Rust needs to fit in with C, C++, Ada, Fortran, Pascal, and all the other natively-compiled systems languages. Using generic system-provided tools isn't just for C. You'd likely use a Makefile to compile Fortran.
The idea is that the languages are interchangable parts with compatibility. You can create a project that uses a different systems language for each source file, run "make", and it all builds. There is no glue code, no interface definition language, no wrapper, no thunk, or anything of the sort.
The expectation is just different. Nobody expects Python to cooperate with Lua or Ruby or Perl, with source files in different languages freely calling into each other. That is the expectation for natively-compiled systems languages.