My understanding of applying MVC/MV* is following the principle of Separation of Concerns (SoC) - separating program/codes into distinct sections/pieces so that each section could address a separate concern (Ref: http://en.wikipedia.org/wiki/Separation_of_concerns)
there are a lot of benefits when separating concerns: one won't affect another and developers could work on a unit without impacting the rest, etc. & etc... MVC is not the only pattern that follows SoC, basically, OOP itself is a great concept to break things into units.
MVC/MV* are very useful when you handling UI related development, while underneath there could be more patterns - factory, singleton, facade and etc. Majority of big projects consist of multiple layers handling different aspects, but UI might not be a must for some cases. You may see MVC a lot - that's because a lot of projects have UI elements.
thus, While talking about the drawbacks of MVC, it really depends the projects you are doing - does it have UI? does it require great scalability/extensibility? does it have many interactions between UI and behind-system? for example, a simple information web page does not require MVC at all, unless you plan to extend it to a great interactive page in the future.
so in order to evaluate MVC (or more general - a design pattern), give it a context and think about complexity, scalability, testablity, maintenance, time constraint, etc. & etc.