This is also why everyone implements their own (buggy) linked-list implementations, etc.
And header-only is more efficient to include and build with than header+source.
Now that I'm thinking about it, CMake also isn't particularly good at this the way most people use it.
But, more commonly I've seen that it's just easier to not need to add C files at all. Add a single include path and you can avoid the annoyances of vendoring dependencies, tracking upstream updates, handling separate linkage, object files, output paths, ABIs, and all the rest. Something like Cargo does all of this for you, which is why people prefer it to calling rustc directly.
I tried to use cargo in the past and found it very bad compared to apt / apt-get (even when ignoring that it is a supply-chain disaster), essentially the same mess as npm or pip. Some python packages certainly wasted far more time of my life than all dependencies for C projects I ever had deal with combined.
Apt is fine for local development, but it's a bit of a disaster for portability and reproducibility. Not uncommon to see a project where the dependencies either have unspecified versions whose latest versions in universe are incompatible, or where the package has been renamed and so you have to search around to find the new name. Plus package name conventions are terrible. libbenchmark-dev, libgoogle-perftools-dev, and libgtest-dev are all library packages from the same company. The second one is renamed to gperftools-lib with RPM repos, to further compound the inconsistency.
I find myself dealing with package and versioning rename issues regularly in the CI pipelines I have using apt.
My experience with dependencies in Debian-derived distributions is actually very good, far less problematic than any other packaging system I ever used. But yes, one needs to maintain dependencies separately for RPM and others distributions. But obviously the problem is not lack of a package manager and adding another one would not solve anyhing: https://xkcd.com/927/ The solution would be standardizing package names and versions across distributions.
Dispute.
This is C code. You can't just drop it in and build it; you have to write code to use it. You have to figure out the API to correctly use it. If memory is passed around by pointers, you have to understand the responsibilities: who allocates, who frees, who may touch what when.
In the first place, you have to decide whether to commit to that library that far; it might not be until you've done some exploratory programming with it that you want to scrap it and find another one.
The cost of adding two files versus one is practically nothing in consideration of the larger picture.
The separate header model is baked into the C mindset; the tooling readily supports it.
Many "header only" libraries are secretly two files in one. When you define a certain preprocessor symbol before including the file, you get the implementation bits. When you don't define that symbol, the header is a pure header.
That means you have to pick some existing .c file which will define the preprocessor symbol and include the heaader. That source file becomes a "surrogate" source file, taking the place of the source file it ought to have.