I've always found MVC or any flavor of it to be a flawed paradigm. Instead, a separation of APIs, and clients that consume them, is a more pleasant way to work with things that need a view layer. "Controllers" are undefined things. We get frameworks like Rails that encourage spaghetti code placement (and make spaghetti a first class citizen), because the fundamental concept of a controller doesn't make sense.
MVC actually works really well for a HTTP framework like rails, because the separation of input (the controller) and output (the view) fits well when your model is based on request/response.
Rails goes a bit far in pushing for your model to be built around your database-backed data model (but does properly push you to include data integrity and business logic there as well).
Since there is not object classification in rails called Spaghetti, I can't really speak to it being a first class citizen in rails - nor can I guess which of Rails' shortcomings you are referring to.
Even with a client/API separation, your API still has input, output, and business logic - the three components of MVC. An API can benefit from having MVC once it has multiple views; for instance, if you later find you must support different clients utilizing multiple concurrent versions.
In that vein, I consider a framework like Sinatra to be controller-centric - with both the model and view layers being optional and bring-your-own. I've certainly used it as MVC.
I think the OP is probably complaining about people tending to put all of the business logic into the controller. This essentially leads the the controller functions being modular/procedural in nature rather than object oriented. And I think that's what they mean by "spaghetti" -- you have either a big honking function, or you have a whole bunch of functions with no clear place to put them. This is made worse with the strategy of "service objects", which are usually not objects, but rather highly coupled modules of functionality that expose all of the properties in a way that is global to the entire module.
However, IMHO the OP is incorrect that the problem is with MVC. The problem is actually with the active record pattern (or, again in IMHO, anti-pattern). In active record, your "model object" has a one to one relationship with the (usually relational) table where you are storing the data. The problem with this is that what makes sense from an OOD perspective does not make sense from a relational perspective. This is why there are entire books written about the problems of object relational mapping.
From a relational perspective, we want to store things in a way that makes the relational calculus cleaner. We want to be able to efficiently store and query the data. From the OOD perspective, we want to increase cohesion for the functionality by grouping common state together. These two goals are usually at odds.
Just like we have a view layer in MVC with respect to the UI, so too do we need a view layer with respect to other kinds of external representations. Probably people don't remember the old, old frameworks where you designed forms graphically for the UI and the system automatically generated C++ code for the "model objects" that could be used to populate those forms. Most people don't know about these because they were an incredibly bad idea that thankfully died out. No sane developer would build their model objects to be one to one relationships with their UI view objects. The same should be true for other representations like the DB layer, or indeed communication layers (serialising model objects so you can ship out the data for a different application is incredibly common, but also incredibly bad). You want view objects to translate the data to and from the model objects.
Once you've done that, then you can design your model objects so that they can sanely calculate your business logic. Your controller object become the thing that they were meant to be in the first place: objects that forward incoming requests on to the model layer and put the result into the view layer.
Rails (at least if you are using ActiveRecord) is just broken. It's not a representation of how MVC should work. It works well enough for some cases, but gradually the stink gets worse and worse until you start asking yourself if there was some advantage to using Rails in the first place.
