I don't think PHP's main problem is speed. It's generally used for websites, and a few milliseconds aren't going to make a difference when pages are so bloated by JavaScript libraries to often be 5-10MB. PHP's problem IMHO is that I wouldn't be able to use it if it wasn't for autocomplete: inconsistent function names, inconsistent parameter order. The ecosystem is fine, there's Composer, PSR, Laravel. The problem is…
I spent 10 years writing PHP, and lately I'm writing Java, Scala and Node code instead. In each case it was due to needing specific libraries that PHP didn't have, but it did give me some insight into what PHP is missing to no longer be the glue layer but a real platform for "serious code":
1. No more ugly mix of procedural and OO code. I want all of PHP's stdlib to become object-oriented, including the primitive types. Also, I need a real type-hinted collections API, not just all-purpose arrays with global functions as primary API. Yes, it's just syntax. Yes, it does matter, a lot, even if you use phpstorm and auto-complete all the things.
2. Generics. Without generics it's impossible to do a properly type-hinted collections API, or a type-hinted FP library. Don't get me wrong, I don't want to type-hint all the things, but I do want to have type-hinted API's to build my own code on top of, and PHP's lack of generics makes this mostly impossible. I can't fix in userland what it misses in its stdlib.
3. A standard story for async and long-running code. Yes, I know about things like pthreads, curl_multi, amp and react-php. I never really felt like any of that stuff was really suited for mature production code and real-world deployment patterns, which is why I always ended up with architectures that boiled down to handing off anything long-running to a queue with separately launched workers processing it in series. I would like an extension to the standard PHP execution model and core language that gives a path towards fully non-blocking architectures as a standard feature.