This clearly shows PHP's origin as a set of loosely related libraries and utilities ties together with a thin veneer of a language. When used as an actual language it's less than ideal. Who's to say curl will still be the default way it makes some requests in the core language later? What if the library changes it's API after deprecating the version that was originally used? Coupling things like that is a poor design choice (unless the thing you're matching is a standard, that's less likely to change in backwards incompatible ways, at least without plans for how to deal with it).
It was a benefit to those that knew C and worked with the same libs there, and it was easier for early PHP developers to include stuff (since they didn't have to develop a separate API and abstract usage), but it definitely contributed to PHP's reputation of being hard to intuit how a function expected to be used.
You can compare and contrast this to Perl, where for the most part they didn't include C libraries in the core (generally they were done as modules, and there are modules that emulate C's calling methods exactly, and those that provide an extrapolated API, sometimes from the base library, sometimes building on the other module), but they did include a lot of the C standard library functions in familiar usage patters, but still altered to fit the design goals and ideas Perl was being developed with (Perl is a highly designed language, it's just that its design goals often make it look haphazard to those that haven't internalized them).
Both approaches have their strengths and weaknesses. I would say PHP's approach was useful very early on, but quickly became detrimental for most users (it was useful longer for devs I imagine), but PHP's other strengths helped mitigate that (IMO, being able to be built into Apache in a manner other languages couldn't imitate well was a killer feature for a long time).