sigh, if API was always optimal because of the magical word API then there wouldnt ever be benchmarks topics on forums, tech articles, and what not to figure out what actually works, and whats to avoid. Sometimes, the code is the most optimal general case, but a general case is that, solves all type of problems that may need the API, as it is an API. Which means it is slower for a specialized case. eg. c++'s myriad read functions, some are safe and slow, some unsafe and fast.

Sometimes the API is only an specification, which means implementation quality is up to whoever implemented it, and not always will it be optimal, or even work as you expect. eg c++ again, java when implemented by others than sun, or mono.

Plenty of times, the developer is like you and goes "hey I wont reinvent the wheel, and just use this API call, which I assume is perfect", except you enter a recursive thought all based on a faulty initial api function, or just the suboptimal version.

The API call may be the most optimal version of an algorithm, for one run, redoing the preprocess step for every call you make.

Oracle or the PHP company may just want to make their language competitive and include popular syntax, without it necessarily be due to performance improvements of said syntax, and it actually being a downgrade.

The developer may just be a moron and no one noticed. Or it is a single-developer API.

I made a language in college as part of getting my passing grade, that doesnt mean my language or any of my peers was optimal (by a longshot).