You don't have to use DrRacket to use Racket.

People doing real work with Racket tend to have "workflow" setups that are closer to SLIME.

I personally used a simpler Emacs setup ("https://www.neilvandyke.org/quack/"), and ended up leaning more on modules and embedded unit tests ("https://www.neilvandyke.org/racket/overeasy/"), and less on very dynamic interactive evaluation like I'd done before.

Though, if you want to monkeypatch heavily, CL is famously good at that.

you can have a REPL in nvim/vim/tmux/screen/another terminal/or any other window , and send regions from your vim buffer to that repl

I have heard that this is not possible because Racket needs to make a stricgter separation of compile time and run time... but I am not sure whether this is actually true.

But, though I don't know current Racket internals, I'm not sure those need to be a barrier to monkeypatching that approaches CL.

Other than optimizations that make some debugging info and dynamic changes difficult-to-impossible, if the system had a mode to disable these optimizations (or to maintain some information in parallel that permits a cascading unraveling of optimizations affected by a change), I'm not aware of a fundamental reason the system couldn't support more loose poking at things.

Though, one implementation complication that Schemes do have is first-class continuations.