I don't think there is much of a use case for it. Production systems manage it in a more reliable way (spinning up a new process, redirecting ports, etc), the risks of problems aren't worth it in that environment. The convenience it provides to developers is not justified by the risk of confusion it can cause. Troubleshoot a bug caused by reloading once or twice and you won't ever do it again...why waste time troubleshooting odd behavior to save a few seconds restarting the process?

Python has the ability to reload code. It has problems, so there are packages to do it better. They all either have to tear everything down, which is the same as restarting the process with a fresh interpreter, or leave objects around from previous versions of the code that may not be in sync with the code you think you are running. You get in the habit of constantly questioning if something isn't working the way you expect and responding by restarting the process. Do that long enough and you will likely decide the worry isn't worth it and you just restart your process.

The best argument I've heard for doing this is that interactive sessions have a bunch of state and you don't want to loose that by restarting everytime you change code. I've worked like this at times, but have found that it's easier to use the REPL for quick experiments rather than complex state because if you want all that state you almost certainly want to recreate it from time to time and the best way to do that is by running a script...so that's what you do.

In short, code reloading seems cool, but has practical issues that limit its utility and can't really be solved due to conflicting requirements.