Is MVC a good paradigm for web development?

It's like you'll get laughed at , if you dare doubting about it.Checking Wikipedia article on MVC you'll see the *myriad* of php MVC frameworks out there nowadays, so, looks like it's definitely the way to go.
But, still, i miss some kind of reasoning of why MVC is such a great paradigm for web development.Sometimes, i get the impression it has been adopted because one was desperately needed.
Of course, there are plenty of sources explaining what MVC is all about.Let's take the definition of "View", according to Wikipedia:

A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state that require a screen update

Now, let's look at the definition of "View" we can find in CakePHP (taken as example):

Views are the V in MVC. Views are responsible for generating the specific output required for the request.Often this is in the form of HTML, XML, or JSON, but streaming files and creating PDF’s that users can download are also responsibilities of the View Layer

Are those two definitions equivalent?For starters, the second definition includes a new concept, that looks like it's not important enough to have its own initial in the paradigm name: the Request.
But, if we continue reading CakePHP documentation on Views, we'll find quite a few more concepts:

The view layer in CakePHP can be made up of a number of different parts. Each part has different uses, and will be covered in this chapter:

• views: Views are the part of the page that is unique to the action being run. They form the meat of your application’s response.
• elements: smaller, reusable bits of view code. Elements are usually rendered inside of views.
• layouts: view files that contain presentational code that is found wrapping many interfaces in your application. Most views are rendered inside of a layout.
• helpers:these classes encapsulate view logic that is needed in many places in the view layer.

So, the view layer, are composed of a few things, one of them being the "views".But the "views", are a "part of the page".Another new concept that is brought up.So, "views" are part of the "view layer", and the "page".Are those two things the same?
Because "layouts" are defined as "view files" that wraps "interfaces".Again, "views" are rendered "inside" a layout, so i guess it's safe to say that views are also part of "layouts".
So, "views" are something that are part of the "view layer", the "page", and "the layouts".
It's worth noting that "page" is a HTML concept.There's no such thing as an XML or JSON "page", and i dont think "streaming files" can be thought as a "page" neither.
Going back to the MVC definition found in Wikipedia, a view "generates an user interface".It could be argued if generating HTML is exactly the same than generating an user interface.But, i dont think XML, JSON or "streaming files" are exactly "user interfaces".

To finish the soup of concepts, while "elements" are "reusable bits of view code" (they are view code, but they're not views?), "helpers" encapsulate "view logic needed in many places".I swear i could write as "reusable bits of view code" as well.
I'll not go into the "view blocks", another concept introduced later in the same documentation.I think it's enough. We have the "view layer","view blocks","view logic","view code","view files" and plain "views".
This way of abusing the MVC definition, using the word "view" repeatedly, only shows how poorly defined are each concept, and, finally, how the documentation tries to twist concepts to make it fit into the MVC paradigm.
Let me demonstrate that: if i pack a certain user information inside a JSON message, what role takes that JSON message in my system? Is it an "user interface", like the "canonical" MVC definition refers to what is produced by the "views", or is it the way a Model residing in the client, is getting its data, the same way the Models residing in the server get their data from the DB?
Is the "V" doing the same job for our system when it sends HTML (data mixed with presentation), and when it sends JSON (just data)? Can you think in a system where the server does *nothing* about the user interface? (Flash? Desktop / Mobile App? Javascript?).Then, how can we call that a "View"?  Whats a "page" in Flash terminology?
This is why, in the CakePHP docs, they've subtly changed a word from the V definition at Wikipedia. Views no longer generate "user interfaces", but "output".Any "output".Way to generalize an idea to finally push inside absolutely unrelated concepts (as if all "output" has the same role in a system..).

You may wonder if i'm attacking CakePHP for some reason.Not at all.In fact, the first time i've visited CakePHP site, has been for writing this post.I know beforehand most MVC frameworks docs will be extremely vague, inconsistent in this point.Because, simply put, it doesnt fit well.But doc writers really try hard.And most people will read those docs trying to learn, not trying to critisize it.I'd have pick any other framework, and i bet the same inconsistencies would show up.

Those are some of the reasons because i'm not sold on the MVC fever.And, also, because i think there are better, more consistent ways to do web development.

PD: Just checked Symfony documentation.In a whole chapter "explaining" Views (like 15 pages), "model" and "controller" are mentioned a whopping total of..4 times! 3 of those times, in side-notes.All the documentation focus on all those little "helpers","elements","layouts" (read: good old scripts)...But nothing about how the View / Model / Controller interact.