Earlier quoted context omitted.
Function names are rather inconsistent. get: gettype get_class str: str_ireplace str_pad str_repeat str_replace str_shuffle str_split str_word_count strcasecmp strchr strcmp strcoll strcspn encode: base64_encode quoted_printable_encode session_encode rawurlencode urlencode gzencode php: php_uname php_sapi_name php_logo_guid phpinfo phpcredits phpversion htmlentites: htmlentities html_entity_decode to: stream_copy_to_…
I have heard—and I do not recall the source for this, so it may be incorrect—that when PHP was originally being written, the hashing algorithm for function calls used the length of the function name as its primary key. Thus, making each function name a slightly different length made the code run faster. Of course it would've been nice if, at any time in the past 20 years, they'd gone back and standardized those funct…
Length as hash was indeed a thing in PHP/FI 2.
Second third to the reason is that PHP often takes names from underlying C libraries. strlen is strlen since that's the C name etc.
Third third reasoning is that early PHPade it easy to contribute. You had a need and a patch - a few minute Slater it is in. Nowadays there is more of a debate and vote before things are added (in my personal opinion too much emphasize on voting, but, well that's how things go, some day the process will be relaxed again ... and strengthend ... and relaxed)
Cleaning this up isn't trivial. There eis sooooo much code written already. There are sooo many tutorials, books, articles, magazines, videos and muscle memory making a change hard, even ignoring that for many things there is no single truth about what is best.
From time to time some modules might see replacements with more streamlined APIs (i.e. Maybe someday one figures out what a good and practical Unicode aware string library might be, which might replace the classic string mess) but those are multi year things.