You don’t have to use neither of them, it all comes down to the application you are writing and how you are writing it.
I myself prefer an OOP approach using some application structure/pattern like MVC. Both because it’s logic that many programmers are familiar with, and since I like the natural dependency injection/modularization you get.
If you consider this controller:
[php]<?php
class UserController {
private $model;
private $request;
private $storage;
private $view;
public function __construct(Request $request, Storage $storage, View $view) {
$this->model = new UserModel;
$this->request = $request;
$this->view = $view;
}
public function create() {
if ($this->request->method === 'POST') {
$user = new UserEntity;
$user->setName($this->request->data->name)
->setPassword($this->request->data->password);
if ($this->model->create($user)) {
$this->request->redirect('user/profile.html');
}
$this->view->set('errors', $this->model->getErrors());
}
$this->view->render('user/register.html', [
'name' => $this->request->data->name,
'password' => $this->request->data->password
]);
}
}[/php]
Here we just inject different parts of our logic into the controller.
The controller does not know:
[ul][li]How we get the request method/data[/li]
[li]What a user entity does with its properties (ie hashing password)[/li]
[li]How the model saves the user[/li]
[li]Where the model saves the user[/li]
[li]How the request class redirects us somewhere[/li]
[li]How views work / are rendered[/li]
[li]etc…[/li][/ul]
So why is this good? Because now we can just swap out big parts of our system if we need to.
Say we have a simple view class that sends the 2. param (array) into a .php view file matching the 1. param. If we want to change to use a template engine (ie Twig), we can just set up Twig where we bootstrap the application and inject that class instead of our old view class. At worst write a view engine (class with a couple of methods) that takes our format and converts it to what twig expects.
[hr]
The same idea can be used throughout the application.
The model may get a $storage model injected, and can then just pass the entity it want to store over to the storage model. That way if we ever want to change where/how we store data from DB to API, CSV file or whatever else, we can just change the storage model and all the logic should work.
Here the model does not know what type of storage it uses:
[php]<?php
class UserModel {
private $storage;
public function __construct(Storage $storage) {
$this->storage = $storage;
}
public function create(UserEntity $user) {
if (!$this->acl->canCreate($user) {
throw new AccessDeniedException();
}
if (!$this->validate($user)) {
throw new InvalidFormDataException($this->getLastValidationErrors());
}
return $this->storage->save($user);
}
}[/php]
We can get some control though. By adding the type we expect in the constructor we do know it extends our interface “Storage”, so we know it contains the necessary methods and return the types we need.
Using interfaces to enforce the layout of different parts of the system will allow us to change them easily in the future as their “core” functionality should be the same (same methods/params/returns).
[hr]
MVC is actually just an application structure pattern. It says to split up the code into the following parts:
Model
Main application logic
View
Simple template files
Should be “blind” from the rest of the application
Can only see the params it has been passed by the controller
Controller
Gets user input (requested urls, get/post params, etc)
Passes the input on to the model where the main application logic is
Shows a response to the user
[hr]
I suggest you try out a couple of simple PHP frameworks. Like Flight, Slim, Fat Free Framework. They all use an OOP approach to building MVC applications.
Note that many frameworks (including the above) use a front controller that bootstraps the application and does the routing. This means all requests to the web server are sent to index.php, and there the routing takes care of which “real” controller/method is initiated.
This is how it’s done in Fat Free Framework:
[php]$f3 = require(‘path/to/base.php’);
$f3->route(‘GET /user/profile.html’,‘UserController->profile’);
$f3->run();[/php]
All requests to yoursite.com/user/profile.html will initiate the profile method in the UserController.
Nifty 
If you get start getting into OOP, the one of the first things to do in my opinion is develop an autoloader. That way you just develop a class and throw it in the appropriate directory. You’re then ready to go for there is no fuss or muss. As for me I think of MVC as a concept of a foundation for a framework (a blueprint) - Model, View and Controller. I’m pretty good with M & C part myself, but I tend to get lazy with View portion. 
As you go along you tend to make modifications to the blueprint, though sometimes at a cost of a headache or two. 