This idea is a little less well-defined that some of the others but it comes from having learned to code in both PHP and Elm. In a nutshell, I feel PHP programmers have been following the Elm architecture for a long time before Elm was invented.
In comparison with Servlets, node.js or other Web frameworks that maintain a server running continuously in the back-end, PHP scripts are expected to load-execute-finish on each transaction. Any state is to be committed to a database (like MySQL, creating the once famous LAMP stack) or an in-memory cache (such as Redis).
This focus on scripts that are loaded, perform a certain service and die has many advantages as it drives the developer towards efficient code that does a few things and it does them correctly.
A rich Web application, in contrast, it is a Javascript program that is running continuously, reacting to the users actions and background events. Therefore, moving from the PHP mindset to a rich Web app mindset can be difficult. But the load-execute-die concept is powerful and useful enough that the Elm programming language brings it to the browser: for each event, the full Web page is generated (off screen) from scratch. The underlining Elm runtime then performs a diff between the actual page and the new generated page, changing only the HTML elements that need to be changed.
While the mindset of the programmer when it comes to writing small, useful programs/functions might be shared between PHP and Elm, the two languages are widely different both in paradigm and programming style. Therefore this idea boils down to: either make a different JS language that implements the Elm architecture with a syntax and style closer to PHP or define a set of programming or build on existing primitives for functional programming in PHP to deliver a closer programming experience on the PHP side.