Because if you're implementing it properly with the advanced features of a language such as Rust, you need to similarly create an entirely different ABI that goes down to the C ABI, increasing the complexity of the implementation because the C ABI has so many edge cases.
Basing it on the C ABI makes it only easier for "simple" languages like C to communicate with Rust.
> increasing the complexity of the implementation because the C ABI has so many edge cases.
Every language speaks C, and whether we like it or not every new language will continue to speak C for the foreseeable (for-C-able?) future. This cost is already baked in, so you might as well leverage it to reduce the cost of a second ABI by building it on top of the ABI you're already guaranteed to support.
What edge cases are there in the C ABI, and what can't you represent with it?
The big problem to me is sharing pointers across FFI which is extremely dangerous in managed languages where the pointer could be invalidated by a GC sweep, but I don't think that's terribly relevant to Rust.
They inherit a lot of issues from C like badly defined types; they imply on some unfit conventions like \0 terminated strings; they do have some issues defining the memory managing model (but I think that's unavoidable).
I have never dwelled on low-level compatibility for long, so I certainly don't know about most issues. But even with a very small view, cleaning the leggacy looks like a very worthwhile thing to do. Maybe after Rust has gained more adoption, we can start to make C adhere to it, instead of the other way around.
The C ABI is (broadly speaking) a standard way to layout structs and a choice of calling convention for the platform. That doesn't influence which types are/are-not defined (and the superset of a C compatible ABI can fix some subtle issues there, like untagged unions).
Null terminated strings are not a part of the ABI, they're a convention in C libraries. Same goes for memory management, that's not really a part of the ABI (but it is an issue, since you need to define who is responsible for memory if it is shared across FFI, but again, the big issue there is garbage collection).
Any difficulty on understanding your types and discovering their sizes will make it harder to use the ABI. Any convention that you decide not to follow will break the interoperability of other software you may call over the ABI. And the C ABI doesn't carry information about memory management because people decided to build it that way, it could very well do it.
But if you want to define an "ABI" as strictly the geometry the data has on the memory when a function is called... well, good luck using that information on the other end to retrieve the data on your function; it's completely useless. But yes, I don't see any problem on it either.
The C ABI carries memory ownership information just fine - you simply pass a struct with two pointers, one for the memory, one for the function that does the cleanup.
Basing it on the C ABI makes it only easier for "simple" languages like C to communicate with Rust.