The article mentions SBCL which is a well regarded open source Common Lisp implementation.
Common Lisp invented REPLs and the way most people use it now answers your question with "both".
A REPL usually runs locally in a subprocess or remotely through a REPL server and then your editor talks to that running Lisp Image where you can send code for compilation and recompilation while the image is running and also interact with it directly through the REPL which includes the debugger.
The GP you are referencing uses the common SLIME[0] package for anything of consequence which works exactly as described above.
So what's left is to answer GP question, which nobody has done:
What are the use cases for using the repl directly rather than through something like SLIME?
You answered "both" which I'm sure is correct, but I'm curious as to specifically which usages you find better directly through the repl. The only reason I can see is when you can't be bothered to (or are unable to) start SLIME, otherwise even to evaluate small expressions I'd rather have them written in a file to easily keep a history of them or edit them.
I also know people who never use tools like SLIME and prefer just using the repl for simplicity.
This was also my impression when reading the article, as someone who uses Sly heavily, every day. I can't imagine not having in-editor access to functionality like recompiling the function at point, or live evaluation of testing forms directly from the buffer. As Stew (the Clojure guy) pointed out in a video from a number of years ago, nobody should be typing anything raw into the in-editor REPL prompt; you should be sending forms directly from the code buffer.
How do I maintain that workflow if I'm to use native REPLs?
It's "both" because if I want to interact with the SBCL REPL in SLIME I swap to the buffer for it and type in whatever I want which includes reader macros and such mentioned in the article.
Common Lisp invented REPLs and the way most people use it now answers your question with "both".
A REPL usually runs locally in a subprocess or remotely through a REPL server and then your editor talks to that running Lisp Image where you can send code for compilation and recompilation while the image is running and also interact with it directly through the REPL which includes the debugger.
The GP you are referencing uses the common SLIME[0] package for anything of consequence which works exactly as described above.
[0] https://slime.common-lisp.dev/