Why use PHP OOP over basic functions and when?

In a lot of scenarios, procedural programming is just fine. Using OO for the sake of using it is useless, especially if you're just going to end up with POD objects (plain-old-data).

The power of OO comes mainly from inheritance and polymorphism. If you use classes, but never use either of those two concepts, you probably don't need to be using a class in the first place.

One of the nicest places IMO that OO shines in, is allowing you to get rid of switch-on-type code. Consider:

function drive($the_car){

    switch($the_car){

      case 'ferrari':
          $all_cars->run_ferrari_code();
          break;

      case 'mazerati':
          $all_cars->run_mazerati_code();
          break;

      case 'bentley':
          $all_cars->run_bentley_code();
          break;
    }
}

with its OO alternative:

function drive($the_car){

    $the_car->drive();
}

Polymorphism will allow the proper type of "driving" to happen, based on runtime information.

---

Notes on polymorphism:

The second example here has some premisses: That is that all car classes will either extend an abstract class or implement an interface.

Both allow you to force extending or implementing classes to define a specific function, such as drive(). This is very powerful as it allows you to drive() all cars without having to know which one you're driving; that is because they're extending an abstract class containing the drive() method or implementing an interface forcing the drive() method to be defined.

So as long as you make sure that all your specific cars either extend the abstract class car or implement an interface such as canBeDriven (both of which must declare the drive() method) you can just call the drive() method on an object which you know is a car (but not what type of car) without fear of it not being defined, as PHP will throw fatal errors at you until you define those methods in your specific car classes.

Using an object-oriented programming approach rather than a procedural programming approach in a program doesn't really depend on the language (be it PHP or not), but on the type of problem you are trying to solve.

(I'm just going to use pseudocode in my examples as I am not too familiar with PHP.)

For example, if you have a program where you are just performing a bunch of functions in order, then procedural is going to be fine. For example, if it's a simple string manipulation program, a procedural approach would suffice:

perform_truncation(my_string, 10)
to_upper(my_string)
perform_magic(my_string, hat, rabbit)

However, if you're going to deal with many different items (such as files, or any other representation of, well, objects) then an object-oriented approach would be better.

For example, if you had a bunch of Cars and wanted them to drive, then in procedural, you may do something along the line of:

drive_car(first_car)
drive_car(second_car)

Where as, in OOP, the Car can drive itself:

RedCar myRedCar();
BlueCar myBlueCar();

myRedCar.drive();
myBlueCar.drive();

And, as each car is a different class, their behavior can be defined differently. Furthermore, they may be both subclasses or Car they may have common functionality.

It really comes down to the type of problem which makes either procedural approach better than object-orientated and vice versa.

Aside from the issue of procedural or object-oriented, it may be a kind of "code smell" to have one source file with many functions. This can also be said about classes which contain many functionalities which may be better performed as separate functions in separate classes.

The issue here may be of code organization rather than deciding to pick procedural or object-oriented programming. Organizing functions into separate source files may be what's needed here than to abandon the procedural approach to writing the program.

After all, there are plenty of programs written in the procedural programming approach which is well-written and easy to maintain.

I'll try to keep my answer as an addition because the answers by Majd Taby and Coobird are really good.

I was mostly a procedural programmer for several years and didn't fight against OOP programming, but never really saw much relevance...that is until I started working on a team and building more important and complex projects.

OOP really shines, in my opinion, when you need to write lean, easily maintainable code for more complex applications. And mind you, not in every situation, but there are some where procedural just won't work that well.

Most of my examples of great OOP implementations are for projects where I had several things that were all related but all slightly different. Sites with lots of forms, lots of users, lots of products etc.

They all have similar behaviour names like print(), update(), etc...but by encapsulating them as objects and varying the methods' implementations in the classes I can make my code at runtime very simple and clean throughout the site. Also, and this one was key, despite having different behaviours, I could work with different objects using the same method calls throughout the entire application. It allows a second developer to work on actual implementation while I work on deeper code.

I don't know if that helps any but speaking as someone who was in your situation not too long ago, I love OOP.