I hate to admit it, because I loved my time with Rails (and I still love the framework), I have a hard time justifying new Rails applications these days. Core team has made some tragic design decisions, and developers just don't perceive it as being "cool" any more. The latter is a terrible metric for which to base a technology decision, but I think you'll find it more difficult to recruit additional engineers if you choose Ruby on Rails.
Without knowing too much of the details, Node/Express (ideally with Typescript) seems like a better solution here, given you'll be building out the front-end in Vue or React. It might be worth looking at NestJS, as it's the closest I've seen to a well-formed opinionated framework on the Node side of things. We're also fans of Objection ORM.
I hope that's helpful!
"Node.js is everywhere" is not the argument to use or not to use it. First - it depends on WHY you need it for your app. Today you can have a very robust and responsive JS front-end with no matter which JS framework (Ember, Vue, Angular, Stimulus, etc..) or library (React, Electron, etc.). I'd say, the most common way to go is to use a Rails API app on the back-end side and a JS framework/lib on the front-end side using JSON API format. Most front-end frameworks offer a bunch of ready-to-use solutions/add-ons for authentication, authorization, file uploads, etc and most of them even have Rails gems for easier integration. So it's up to you make a choice for a good one. I used Rails+Ember, deployed on separate platforms. Advantages of splitting into 2 separate apps are: each of them can be developed and deployed separately, you can have 2 separate teams working in their own way. And even if you have to replace one of the app by another framework/language (Java, Elixir, Vue, Angular, etc.), you can also do it separately, - JSON API standard will stay the same to exchange with data.
The pervasiveness of the technology should absolutely be considered in your selection. It impacts everything.
The libraries available, the talent available, the security and maintenance of the tool and its peripheral technologies; it all correlates to how widely it is used.
We don't develop in an isolated vacuum. The community around a technology must be considered.