My personal experience is that the bulk of the time these rewrites don't end up delivering the performance increases that people expect because they don't really understand what's making the prior system slow and don't develop good enough requirements
This is not saying you shouldn't, it doesn't really matter to me. But I think a lot of the time this is driven by engineers who feel like they need to do this rather than a financial decision to save money
My experience is along the following lines (same for Django as well actually):
1. Company started as Rails monolith
2. Some components of the Rails monolith stretch Ruby capabilities beyond where "throw more servers at it" is still reasonable or effective
3. Factor out some backend functionality into dedicated services which can be scaled separately, Rails still serves as the API gateway calling these services. Anything without scaling issues stays in the monolith for now.
4. Eventually Rails is just an API gateway, no one in the org knows Ruby/Rails and its dependency management madness any more, and it gets replaced with a more-performant, purpose-built API gateway, usually something off-the-shelf.
This is not saying you shouldn't, it doesn't really matter to me. But I think a lot of the time this is driven by engineers who feel like they need to do this rather than a financial decision to save money