Not parent but - I mean you're basically right. Ruby is going to force you to use more files than say React would generally, as in React you can put the styling, API calls, data display and html/javascript state code all in one place (for multiple components in one file) as a realistic and fairly normal strategy.
In Ruby however each object kind of gets its own set of three things, three files - Views, Models, Controllers - which means if you have a lot of things that do very little each, you end up with lots of files and switching tabs.
For how my mind works, I dislike this, as every simple Controller kind of looks like every other. It gets predictable, but grating. I personally struggle to read/maintain large MVC codebases because of this - having 3 controller tabs, 1 view tabs, 3 model tabs open to understand something that might be 3 files in Next.js is pretty difficult for me. But the predictability to know that it will be that way does give certainty and save some time when I am new to the code and somebody else has written it.
I'd take Ruby or a similar framework approach (e.g. OG Angular, Laravel, Java EE) if you have 8+ people working on the project. But for projects smaller than that, the beauty of having things in one place is very useful, and pleasant to the extent that most components look quite different and you can remember them that way. You can search for HTML from inspect element and probably find the state logic/processing from the API/backend causing a bug immediately. More recent frameworks and next.js (e.g. fire-svelte and server actions) allow backend code to more readily - yet securely - be placed near client side code, in a way, like PHP.
Also another big part of the background is that views were kind of like a sane version of the JS hell. Javascript until ES6 had many flaws; Ruby views kind of offered a sane alternative; your variables and logic were local, you could work on the visuals in isolation, you could compose them within each other dynamically and without issues where say, some code assumed there was only one of a certain element. But React components offer all that too, but in JS, the natural language of the frontend, necessary for things like click/hover/API calls/media rendering/media recording/permissions/storing data easily.
OOP and MVC are dropping out of fashion in Colleges as Java loses dominance to Python/Javascript there. Ruby is less strict and more terse than Java - you can just procedurally run it to process files for example, in Java you'd need the whole public static void main thing going on - but most people use Python for that these days.
in early JS versions, you had to rely on this pattern called "callbacks" for many actions. Callbacks were hard to read and infamously hard to debug with strange variable scope issues (resulting in a workaround ".bind()" with its own flaws), variables were often global or accidentally changed, rarely immutable with unfortunate side effects, and types and type comparison is strange (and remains so today). Worse, the general pattern was to include scripts and create snippets/elements with IDs or classes that would be "activated" by the javascript. This was good but could go terribly wrong. If two scripts happened to re-use the same code or class ID in global scope, or you yourself accidentally did, you could get all sorts of bugs, even some caused just by the ordering of the imports. React put it's foot down on this and closed off the scope using props, while allowing you to manage state, use HTML, and include CSS. I will admit I am ignorant about Ruby in 2024; but, to my mind, ES6 rising phased out Ruby.