Sure, if all you need is a mildly dynamic page the full blown MVC frameworks that are "standard" for other languages probably seem like bureaucracy to you. But they have their uses, and they also exist for PHP for a good reason. MVC makes massively complicated systems easier to maintain, especially if there's more than one contributor.

Example: I'm responsible for maintaining a "classic" ASP project that's evolved over many years ('98 was the oldest code comment I've found). A report has the wrong value for the record on it. Where do I go to find the source of the error?

You'd say "look at the page that edits that value". Well, sure, but there are dozens of pages that edit that database table plus dozens of other processes that could be altering it (stored procedures, print processes, scheduled tasks, people manually writing SQL statements, etc), looking at all of them would be a huge headache. In a MVC system, I would just go look at the model file of that table and debug the methods it uses to manipulate the database (that's simplified, but it's much less work than the spaghetti alternative).

That is of course assuming that the person who wrote the original code actually understood how to use an MVC framework.

It seems to me that most peoples default assumption upon encountering one is to use the Model as a simple abstraction to the DB and stick all of the logic in the controllers (with many controller methods calling methods in other controllers).

It would help if web frameworks that have precious little to do with MVC would stop trying to piggy-back on the term. For example, if your model, view and controller have a control flow that makes them three layers in a stack, with the controller sitting between the model and the view, then your architecture is not really anything like MVC at all.

The common architectural pattern for web apps where you have a request handler that talks to a database and then generates its output by filling in a template is popular and widely applicable. However, I think the way some of these frameworks tried to hijack a well-established term for publicity in the early days has come back to haunt them now they are better known. Today, if someone wants to learn how to use these web frameworks, particularly the common underlying concepts and design skills, and searches for "MVC", they find a whole load of other information that doesn't really make sense in the context of web apps.

Similarly, anyone who really does want to learn MVC in a context where it is more applicable -- including designing larger JS-based applications that run primarily in-browser, for example -- comes up against a lot of material that is in some cases almost the antithesis of MVC, which doesn't help there either.

When the most common reasonably simple architecture beyond PHP's everything-is-a-template starts off at such a disadvantage, it's not really surprising that many people struggle to understand the basics and just stick with PHP's "it just works" instead, despite the other disadvantages they suffer in making that choice.