First, I think you overestimating the upgrade tax of Rails, and underestimating both the value-add of Rails and the upgrade tax of any other library.
In my experience, the most painful upgrades just as often come from random gems (or gem interactions), or ruby itself. You aren't going to avoid this pain by using Sinatra. If you choose only low-level libraries and you roll everything yourself, then yes, you can potentially avoid this pain, but now you're reinventing a lot of wheels.
It's not just a matter of a gem saving two weeks, it goes to the very heart of the buy-vs-build question. Assuming the same quality of work, upgrading a well-maintained gem is going to be less work than maintaining the functionality yourself. The conventions and tight coupling of Rails may run counter to architectural decisions you want to make, but on the flip side they prevent a huge amount of bike-shedding (I didn't appreciate this until I jumped onto a legacy Django project and discovered a different flavor of chaos). Assuming you have the chops to design a better architecture from scratch, and assuming you put forth the effort to achieve a similar level of polish to what you get with large community-driven open-source frameworks like Rails, you still have to document and enforce your style guide and architectural decisions, and train your engineering staff on them in a way that you get for free with every Rails dev. On balance if you are building typical web applications Rails gives a ton of value, and if you are using a non-trivial subset of features then the upgrade tax is probably lower than curating your own stack, and much lower if you are re-implementing parts of the provided stack from scratch.
The important question is not really Rails vs Sinatra, but rather the stability of specific libraries. In that regard I used to consider ruby the most unstable and I would recommend against using ruby for anyone that cares about maintenance cost. However over the last few years it seems like Ruby has stabilized significantly (Rails 4.0 => 5.0 was dramatically easier than Rails 2.0 => 3.0), and Node has really taken up the mantle of moving-fastest-and-breaking-the-most-things.
My general feeling is Rails is pretty effective for any significantly sized web backend, even if it's just an API, as long as it's talking to some kind of relational database and make use of Rails RESTful routing conventions. If you're talking microservices then I would prefer Sinatra, but at that point I would probably consider Go or Node or Elixir for the improved performance profile that likely would be a more primary consideration if I was going down that route in the first place.