Wordpress is a kind of MVC. Anyway, this is a pull-type MVC layout, where View 'pulls' the data from the model. It does this in a very efficient way, instead of using many different objects, but it actually makes it easy to write patterns on the front panel in many ways.
It also gives views some degree of controller logic (thus, sorta-sorta MVC).
Lets do this: Wordpress gets the url. The wordpress kernel acts as a controller and determines what initial queries to start the database and by extension, what kind of load should be loaded (category view, single message or page view, etc.). He then sends this INTIAL request and sends it to the view file.
This view file may be a strict display of only the file or it may request additional information / requests outside the built-in. This is an MVC pull type in which a view displays data from a model instead of “pushing” controller data from the model into the view.
Thus, when the view sees the code loading the sidebar or widget area, it requests this information. However, which widgets should be there, determined by the controller, which looks at the model, which widgets are on the side panel, and then selects those that are installed to display on the current page, and returns them to the view.
The fact that every part of this object is not an object does not make it less than MVC. You can change the core of WP without (necessarily) changing anything about the topic. Similarly, as long as you use the built-in functions like "get_pages ()", the model and database tables can change while these functions still return the correct data. Thus, the model is independent of the view, and the controller is also independent (unless the view adds the controller logic to do more than the kernel usually does).
While you have a model object containing several methods, etc., such as WPModel :: get_pages ("blah blah"), and contain everything that way, there is still a fundamental separation of problems.
View: template files Controller: WP core Model: various functions that process specific data processing.
So far, names, arguments, etc. If they remain unchanged (or just add new ones), then the separation of problems is preserved and can be changed without disturbing others.
This is not a super-clean version of MVC (especially when hooks are involved), but at a basic level, it starts there.
And being a sequel about this is not bad, IMO. The request from the website is pretty much a continuation in its essence: it is a process with a clear start and end, and it just needs a procedure to process the request, receive data, package, and then skills. You can customize these steps with the objects and methods of OOP objects and layouts (which will simplify some things), or you can simply write many function calls and separate them this way. Class members, such as private variables, get lost this way, but depending on the needs of the application ... you might not care.
There is more than one way to do development, and WP sits on 20% of websites, so it does something right. Probably, something is connected with the fact that people should not study / memorize complex class hierarchies in order to get a database in order to answer the question "which pages are child pages of page x?" and handle this data. Could you do this with OOP? yes, but if Joomla is an example of how difficult it is to implement a complex user website with OOP, then WP will be faster and faster, and time is money.