What does a controller do? In a backend context? It's responsibility is extremely clear: pass along user input, and determine the response path (e.g. if error return this response, else return that response).
It's funny, but the concept of "model" is actually what doesn't make sense. There's no intuitive understanding of it. Controller is straight-forward - handle input, return a response (in terms of PHP). It has a clear, well-defined responsibility. But "model" is a nebulous, abstract idea that roughly means "all the stuff that doesn't belong in a controller or view", which has lead to people thinking they need 6,000 line-long "model" files, whatever those are.
When I was a kid I built model cars and airplanes. Intuitively, model means "a miniature but realistic imitation of something". The phrase "to be a model citizen" means to be an ideal to which you should aspire. The phrase "our climate model can predict global temperatures 20 years in the future" implies an analog of something.
NONE of those common usages of the word "model" aptly convey the idea of what a model in MVC actually is, or what its responsibilities are. It's unintuitive.
So really, it should be VC, not MV. Model is what the anti-pattern is (especially in modern day PSR4 autoloading), not controller.
But really, MVC was never an architecture to begin with, let alone one for the web. It was a simple pattern within the presentation layer only, which is far more applicable to what Javascript is.
So given that, here's how MVC is meant to be applied in Javascript:
A model is a bucket of data to be shown in a view. It contains STATE. This is effectively a viewmodel. The difference between model and viewmodel is hairsplitting semantics. MVVM is a silly pattern because of this... you don't need TWO things called "model".
A controller listens for input and tells the model how to change. The model's responsibility is NOT to listen for input events (clicks, field changes).
A view is what presents the data, and is bound to model state. When the model changes, the view changes accordingly.
Note that this is only the presentation layer. The "model" is not "the rest of your application". It is literally just the state of one or a handful of related UI elements, nothing more. The entire application architecture is a layer that lives UNDERNEATH MVC. Models (and controllers) might make use of the various classes and services in this layer, but they only reach in and get what they need.
So to answer OP's question, MVC is the right approach when you apply it as a pattern within the scope to which it was intended: the presentation layer. When you try and make it your ENTIRE architecture, you're going to fail.