The problem is that people like you will continue to deflect the problems away because you're not competent enough to understand them in the first place. You don't know your code is broken.
The fact that you don't know that the type system is broken means that you're wholly unaware that any code you have written involving integers can behave completely differently when you move your codebase from a 32bit system to a 64bit system. It means you probably don't realise that your code is failing when you expect '0.0' to translate in a boolean expression to 0.0 as '0' does 0. It means you probably aren't aware of bugs stemming from the fact that the confused implementation of arrays such that they're partially ordered list, partially hash maps, but that the inherent conflicts that arise mean they fail at both can create nonsensical iteration. It means you don't realise that you have to explicitly declare a global as global, but if you do it might not actually be global depending on where you make the declaration.
But perhaps maybe you do know these things, you're just too much of a PHP fanboy to accept that these sorts of gotchas and faults you have to deal with are problems that people using almost any other language do not. Perhaps you've simply sold it to yourself that it's okay that these inconsistencies and this poor design exists on the language, because you've fallen into the trap of becoming a one trick PHP pony and have cornered yourself with nowhere to go. I've yet to meet anyone with a broad amount of experience across multiple languages (and I mean working on multi-year projects with different languages, not just hacking something together for a day) that really believes that PHP is somehow equally as good as everything else - when someone is genuinely experienced enough to be objective, it becomes obvious that PHP is just a poor choice. I know this precisely because I have not just worked on, but led a multi-year PHP project and have worked on multi-year Java, C#, and C++ projects too - I know that PHP is just objectively bad. It didn't stop us delivering on type and on budget, but it did cut our profit margins by about 10 - 15% on the project compared to if we had used C#, Java, or even RoR.
You talk about customers and revenue streams, but that's exactly when PHP's faults matter - what's a customer going to prefer, PHP with it's higher development costs because of the sorts of poor design above requiring greater development effort, greater unit test coverage, and/or greater testing, or the language that doesn't have those problems and lets developers get things done faster because they don't have to deal with them or even a remotely similarly sized amount of equivalent problems as PHP has and still often get a performance boost to boot given how painfully slow PHP is and how terribly it handles threading (meaning it's blocking and limiting requests more than is optimal).
PHP is fine if you want to do a "doesn't matter" hack project quickly and dirtily, but when professionalism and money is involved it's about the worst option going - it's quirks, problems, and low performance add an inherent cost increase to any development done with it. If you don't understand this it's probably because you just don't know any better, as you've proven with having to even ask the question as to what's broken with the PHP type system.
The TCO of PHP is the overriding reason as to why it's a bad choice, and that's why I'm surprised you try and write off it's problems by implying they're not an issue in the real world when money and customers are involved as that's precisely when it's quirks do become a problem. Obviously you've never had any accountability or responsibility for delivering a project with maximised profit margins, maximised customer happiness, and maximised stability, performance and maintainability or you'd know full well that you've spouted an awful lot of nonsense.