This is somewhat true, but that is why separation of concerns is a best practice. Maybe you do have one piece of the stack "locked in" to Rails, but the rest of the stack can stay in place if you want to move from Rails to a different framework.
In Rails, this is unfortunately somewhat difficult (though not impossible) to achieve due e.g. to the autoloading magic that Rails adds and that can make isolating library code a bit more challenging if you're not aware of some intricate details of Ruby's and Rails's loading behaviours.
Not quite the same. I moved away from Django some years ago when I ran into a bug that I traced back to the Django ORM. At the time it was neither obvious to fix nor easy to replace the Django ORM with something like SQL Alchemy.
It’s not necessarily about avoiding rewriting entirely, but rather minimizing the amount of rewrite required if you have to improve, change, or fix something. If your roadblock is in the framework, the bigger the framework, the more you have to rewrite.
Even if you opt to go framework-less you are now locked in to whatever you are building.