I feel like this isn't asking the right question. The answers you're going to get are going to be a combination of a) people's perception of what Rails and Django can do and b) people's perception of what the future of the web.
So, let's first look at what Rails and Django can do. Ruby and Python are both slow languages compared to Java, Go, C, and even JavaScript (thanks to companies pouring a lot of work into it). However, computing power is increasing. In the Ruby and Rails world, there has been good work on JRuby, Puma, etc. to help concurrency and move away from the process-based concurrency model. I'm less familiar with Django here, but Python does have frameworks built for concurrency.
Now let's look at Node.js, Java, and Go. All three have good support for handling multiple connections within the same process (via. eventing, threading, and goroutines). Rather than taking up a process per connection, they just add a little bit of RAM overhead and get to stay in the same memory space with cheaper context switching (or none in an evented system). That deals well with long-running processes that would otherwise block a process, tie up RAM, etc.
So, Rails is improving its support for running in a threaded environment and while I don't know as much about Django, Python does have other options addressing this issue. But as it stands today, alternatives have a speed advantage and somewhat by-default operate in a better way for concurrency.
Now, if we're looking toward the future, what do we need this for? We don't need this for things like serving CRUD. If you're trying to keep lots of connections for a chat application waiting for a response, that can be better served by alternatives. However, it should be noted that 37signals does chat via Rails. When thinking about the future, you should think about what is happening in the application and how that affects things like context switching, RAM usage, etc. I don't want to predict the future. If you want to, think about how applications may work that would be better served by systems that don't rely on process-based concurrency.
As some unsolicited closing advice, I find that a lot of people spend an inordinate amount of time worrying over their tools. They want to pick the one set of tools that will last for eternity. Just as your laptop will age and be replaced, the code you write will. Obsessing over tools keeps many from doing anything. There's a lot of low hanging fruit. I'm guessing you see things you want to build - things you could improve upon. Don't worry about having to modify, extend, and do things differently in the future if it's keeping you from doing anything today. Tools are just that: tools. They aren't your product. They're meaningful. Using a better tool is more enjoyable and can create a better outcome. But don't obsess about it trying to guess the future and insulate yourself from future work. Build!