That's partly an exception that proves the rule and partly not a typical case. Uniquely, OSs get to reserve names for themselves (like time, syscall, reboot, etc.). Third-party libraries and other code have to do funny prefixing to avoid name collisions. OSs also have relatively few source code dependencies and, when they do, they get to dictate them.
There are other reasons that C doesn't scale well to large software systems. For example, C's relatively limited compile-time error checking, which leads to using conventions (especially naming conventions) to enforce good practices where tools and good typing would do the job better.
I understand what the expression means, and that's what I meant (though perhaps I could have been more clear). *nix (and libc) are exceptional in that they got first dibs on the symbols they wanted due to being there first. So it proves (while justifying) the rule that you have to prefix all of your symbols unless you're Thompson or Ritchie in the 70s. Even now, in newer C features, extra acrobatics are done to avoid name collisions (_Bool in C99 for example).
But this is really a side issue to my original point: C++ and PHP are categorically different since there aren't strong alternatives to C++ for many types of problems. Though it is possible that other languages are eating at the edges of what C++ is good at.
Single data points never tell you a tremendous amount. People can and do write good software in languages that are poorly suited to the task all the time. No one is saying you can't do it; just that it makes your life significantly harder than it otherwise needs to be.
The success of C++ provides a wealth of evidence that C isn't really up to the task -- everyone seems to hate it for its complexity, but very few people are writing web browsers in C89 these days.
Linux says otherwise.