> For most people Python/Javascript also does the job

True, and people should use whatever works best for them/for the job, no questions asked.

But they also have nowhere near the same experience even though they technically have REPLs. The way a JS/Python dev typically use a REPL is experiment in the REPL itself, then when happy, write the "real code", while a Clojure developers write "real code" all the code, sending selections of code to a REPL in the background, viewing the results in their editor, and just saves the file when they're happy. It might sound similar, but very different experience.

> However, learning a Lisp also makes you a better coder because of immutability and less side-effects. Hence why Clojure is still around.

I don't think "immutability" and "less side-effects" is something lisps in general/all lisps promote/facilitate, it's mostly a thing that Clojure (and children) sticks out for caring a lot about. Scheme/Common Lisp is about as immutable as JavaScript is, and lots of CL programs/code out there spreading mutation all over the place, while in Clojure it's pretty common to just have small "pieces" of mutation in somewhat centralized location.

> learning a Lisp also makes you a better coder

It can do, but it also can make you a worse coder. Specifically in typed languages.

One of the issues I've ran into with Clojure devs doing Java is that instead of relying on a type, they tend to want to write stuff like `Map<String, Map<String, Object>>`. Even when the key sets in both maps are well known.

This becomes worse when you mix that with Immutability. Immutability can be fine except when you need a mutation. In applications that require heavy mutation of data a `Map<String, Map<String, Object>>` is one of the worst ways to represent structured data, copying that structure is EXTREMELY expensive.

This isn't to say that you shouldn't usually strongly prefer Immutability. But it's also to say you shouldn't underestimate the cost of allocations and copying data.

Theres always tradeoffs. Part of being a good programmer is knowing when those tradeoffs are best applied.

I think it's "around" because it's quite productive and sits on a rock-solid runtime with support for an astonishing amount of libraries.

Around these parts it's common to have read and appreciated Paul Graham's old writings about becoming a better software developer through Lisp, and that would be Common Lisp, i.e. very mutable, commonly object oriented.