Introducing a make script for PHP projects should
add significant advantages. Else you're just introducing a new
dependency where historically there wasn't - and complicate its use
for newcomers.

PHP, albeit less so than Ruby or Python, already provides heaps of
dynamic runtime capabilities. For example variable variables are a
core feature of PHP. And with some care even dynamic method or class
creation are often an option. Don't use preprocessing just to eschew
newbie-focused "Xyz is evil" and microoptimization memes.

Yet feature branching is actually pretty simple with existing
tools. For example diff
can not just create patches, but also inject macroprocessor #ifdef
rules per -D flag:

diff -D PKG_PREMIUM page.php page-extras.php > page.src

That'll generate a source file suitable for phrep or any preprocessor.
Oftentimes works for diffing multiple variants even. Which can be
simpler than managing diversifying VCS branches for each variation.

And of course code templating is a practical phrep use case.

For example the slim PARAMETERIZE@() macro might
be usable as-is for many database APIs. It allows to manage a terser
table gateway collection.

Foremost code templating can help with swapping out a concrete implementation
without having to adapt source definitions.

Consuming C header .h files is an accidential by-feature of phrep.
Albeit the use cases within PHP are pretty rare, since most system calls
are abstracted away.

However #include <errno.h> could be used with fsockopens $errno
instead of plain boolean checks.

Or #include <ext/mysqlnd/mysqlnd_priv.h> bound for a few PDO
error codes like CR_OUT_OF_MEMORY.

But if it's just a few constants, copy+pasting them in or just codifying
magic values remains preferrable to preprocessing.

Making authorization-related code paths preprocessor-dependant is a triple
edged sword. - Most PHP frameworks tightly integrate authorization
facilities already. And therefore should just be left to themselves.

Adding conditional #ifdef sections to cement code paths and reduce
runtime ambiguity is tempting, but in fact just adds another
configurability layer. If code is made dependant on preprocessing
before deployment, then at least always add fallback code: