In the end, PHP wasn't great, but around 2000 it was a great intro to building things on the web.
PHP is hard to beat for development velocity. Edit a file, refresh a page in your browser, see the results.
Now that people are back to writing their applications in languages that aren't as slow as Ruby they have often moved back to the CGI model, now branded as "serverless".
Verbosity of a language/framework is meaningless now. Pick a language or platform that makes it as hard as possible to write insecure code, no matter the tedium, and let a coding agent bang away on the keyboard for you.
Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.
If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.
PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.
As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.