OOP vs Procedural

The idea of 'reusing' code existed long before OOP, functions are the ones who solve that: isolated from global scope, any variable names, reusable code.

What was not pointed in this article, is the idea of using "pointer", OOP guys usually avoid this talk, because it breaks some of their valid points. Example: you have function like fopen, which returns pointer, and then you call other functions for manipulating file by submitting to them pointer from fopen.

Using classes just because they are classes is pointless, the only good reason to use them is for their "special" or more complex features.
However, there are ways to add features and functionality of OOP to procedural.

The "easy to understand code", this particular argument has nothing to do with OOP and Procedural, you can in both cases make your code hard to understand, or easy to understand, by grouping it, e.g. have one main file, file what does calculations, file what generates display; adding comments etc.
Seriously, forget that this argument exists, when you compare two coding styles.

The performance question, well... OOP is bad on that topic, Procedural can be no better. In order to achieve highest performance, you can forget about understandable and reusable code altogether. This, however, doesn't mean what you can't do anything about improving performance, simple tricks work both in OOP and Procedural styles.

To summarize everything: use OOP if you want to, but if you find it difficult to work in procedural, perhaps it is your mind what can't handle PHP, not PHP programming problem?
I can easily handle my own code: 1,000lines of avg. complexity barely commented(1 English word per 4lines) procedural code per file, after +/-6months, in less than 20min I can recall whole flow of code, and continue programming.
Maybe I don't understand this "hard to understand and follow", perhaps we are talking about a class containing 5,000lines of un-commented code?

Well, the article focus was mainly on encapsulation. That is meant to bundle the access to data structures into an object to avoid collision of names of functions and variables.

It talked about using only global functions and avoid function names using prefixes.

In the case of the fopen and related functions, the f letter is the prefix. That can work if nobody else uses that prefix. This means that there must be an agreement between developers of components that you may use in your project to avoid that prefix.

In the case of f functions (fopen, fread, fwrite, etc...) those are functions built-in PHP, so the prefix is reserved. No other set of global functions can use that prefix. So, if want to create a new component based on global functions you need to avoid picking the f prefix.

Using classes you do not have much that concern. The names of all functions inside a class do not collide with the names of functions in a different class.

PHP allows you to define new stream handlers to handle new types of protocols or file like access that would work with fopen, fread, frwrite. etc..

Ironically, the way to create new stream handlers is to create new classes that need to implement functions with the same names. If it would use global functions to define new stream handlers, the names of the functions would collide and it would not be possible to distinguish from which stream handler functions would be the different functions.

Other than that, the article did not mention anything about easy to understand code, but rather easier to organized when using classes. This has all to do with the above. Functions with the same names pertaining to the same classes will not collide with functions of other classes. So you do not have to be concerned to use in the same project distinct classes that have functions with the same names.

I agree with you, global code and classes can be equally hard to understand. That was not the point.

The same goes about performance. Actually, people absolutely concerned about performance maybe should not be using PHP or any dynamic language because they do many things in a very inefficient way in terms of performance just to be flexible, but there is significant performance loss, regardless if you use only global code or classes.

"Well, the article focus was mainly on encapsulation. That is meant to bundle the access to data structures into an object to avoid collision of names of functions and variables."
I must admit, getting rid of prefix is in some cases impossible, BUT, we can use some tricks:

Variable collision:
Can be solved with functions and pointers.

Function name collision:
cannot be solved, but, there is this trick, which can be combined with pointers if needed:
<?php
$FILE=array('open'=>'fopen','read'=>'fread','close'=>'fclose');

$fh=$FILE['open']('foo');
$c=$FILE['read']($fh,10);
$FILE['close']($fh);
?>
What this also allows, is alter existing functions with your own:
<?php//alter default
function my_custom(){
//do some stuff
}
$FILE['read']='my_custom';
?>

On performance topic, strictly speaking of PHP, and RAM usage, in some cases, not optimized code vs heavily optimized, can mean easily X2 performance(for same money, you can handle X2 visitors), sometimes can be optimized in hundreds of times, this depends though. And if we are speaking on scale when it means to pay 1,000USD/month vs 2,000USD/month, some might go for optimizing.

The question is why would you want to avoid using OOP and use global code precisely to emulate what you can do using OOP naturally?

The matters of performance is that you are assuming that code using OOP is necessarily slower, which is not a rule. You can write slow code whether you use OOP or not.