A higher order function (HOF) is a function that follows at least one of the following conditions −

• Takes one or more functions as arguments
• Returns a function as its result

source

And then From the PHP Void RFC:

Since return; and return null; are technically equivalent in PHP; when a return value isn't specified, PHP will produce null for you. However, choosing one over the other suggests intent. If you specify a value, it suggests the value is significant. In a void function, the return value is insignificant: it's always the same and has no actual usefulness. Specifying it explicitly with return null; is pointless, because it doesn't really matter what value the function is going to return.

(My highlights)

Therefore there's simply no need to provide a warning and it would simply require the usage of another function and additional significant compile-time overhead to notify a return error on a piece of code that is deliberately intended not to return.

Think of it like this:

• I will keep lots of sponges on standby just incase the empty milk carton gets knocked over.

The carton will always be empty by intention so there's no need for going down the shop and buying 12 super absorbant sponges!

To view exactly which functions would be called, try exploring the (open source) compile-time error handling logic of PHP 7; to see what functions will be called to process a function that causes a similar error (such as returning an unrecognised or incorrect type).

These functions will be the ones that are not called by silently returning null instead of an error on PHP 7.1 intended void return types.

The problem are cases like these:

class Forwarder {
    public $obj; // Some object
    public function __call($method, $args) {
        return $this->obj->$method(...$args);
    }
}

class Obj {
    public function returnsVal(): int { return 42; }
    public function returnsVoid(): void { return; }
}

$fwd = new Forwarder;
$fwd->obj = new Obj;

// We want both of these calls to work
$val = $fwd->returnsVal();
$fwd->returnsVoid();

This code can handle both void and non-void functions. If using the return value of a void function would warn, then we wouldn't be able to write this code and would have to do something like this instead:

class Forwarder {
    public $obj; // Some object
    public function __call($method, $args) {
        if (returns_void($this->obj, $method)) {
            $this->obj->$method(...$args);
        } else {
            return $this->obj->$method(...$args);
        }
    }
}

That's a lot of unnecessary boilerplate, not to mention that ''returns_void'' would have to be implemented using expensive reflection calls.

As an addendum to Martin's answer, I believe that the following section from the Void RFC is also useful in clarifying the issue:

Use of void functions in expressions

In some other languages, such as C, a void function can't be used in an expression, only as a statement. Since this RFC adds a way to specify a void function to PHP's syntax, it might be expected the same restriction would now apply in PHP. However, this wouldn't match precedent. PHP has had 'void functions' of a kind since its inception, in the form of built-in functions, which are documented as “void” in the manual. Such functions can be used in expressions, unlike in C.

We could change PHP's rules on void functions and disallow their use in expressions, but this would create a backwards-compatibility issue: it's not inconceivable that existing PHP code relies on being able to call built-in void functions in expressions, and plenty of code assumes that you can take the return value of an arbitrary PHP function (a callback, perhaps).

Moreover, IDEs and other tools can warn the user when the return value of a void function is being used. It isn't strictly necessary for the language itself to cover this.

https://wiki.php.net/rfc/void_return_type#use_of_void_functions_in_expressions

TL;DR

PHP already had void builtins that were allowed to be used in expressions, and changing that now would be a big BC break.