I'm curious what language and workflow you prefer? In my opinion, there are plenty of other technologies (quite popular ones at that) that have a specific workflow considered "best practice", arguably because "it's just the only one that works".
I prefer any language that requires nothing more than a text editor (any) and possibly a compiler. Where you can use any build system you want and be pretty much just as productive.
I agree that there are other languages that suffer the same problem, the .NET languages for example (except kinda F#), but there are plenty that do not (C, JavaScript, etc).
Well, sure you can use whatever tools you want for C, JS, etc., but then when you contribute to a project in which somebody else made the decisions (either on the job or an open source side project), then you have to learn a whole different set of workflow tools, including all of their quirks and bugs. To me, it's a breath of fresh air to be able to look at a Clojure project and immediately know where to go to find out what dependencies are pulled in, know how to run the project, etc., instead of having to dig through somebody's mad collection of Bash scripts that invoke some weird build tool that I haven't been exposed to.
Clojure (and ClojureScript) have stand alone compilers and ship very nice APIs to compile code (if you want to write your own compiler). People use lein (and its plugins) because mucking around with a compiler and then managing dependencies, setting up your classpath manually, and writing a test runner is a waste of time.
As far as text editors go, you're not forced into using an nrepl-enhanced client. I got by fine on tmux+vim with no editor support for clojure other than syntax highlighting and rainbow parens for a long time. That said, having paredit, nrepl (for code completion, dynamic eval in the correct context, documentation lookup, misc other plugins), and a test runner with easy macros in my "ide" makes my experience better. There's absolutely no reason why one couldn't just use a notepad and the clojure compiler plus whatever random build system strikes their fancy.
C brings in its own problems. Compiler (in)compatibilities, the need to install libraries on a machine to be able to compile and run programs. And besides, in C you still have a build system problem - Make is fine, but it is definitely opinionated about how things happen, and you potentially have to write a lot more boilerplate to get a complex project built with Make than you do for Leiningen, Maven, SBT, etc.
I personally find that to be a horrible experience. Nothing worse than having to install a bunch of tools that you'll never use again, to compile someone else's project. For example, if you use CMake, tough, project A uses autotools. You use bjam? Project B uses QtCreator/QMake. You use Waf? Project C uses SCons.
No thanks, just give me a standard build tool like leiningen and be done with it.
(Ok, so its not "usually" that drastic, because there are only a handful of winners, but its happened a few times now that I've had to install Ruby - a language I don't use myself - just to run Rake to build some non-ruby software I've wanted...)
If I'm a developer, I've got the problem I mentioned. If I'm a user, I only have the problem if I build from source.
Either way, with a standardised build tool like leiningen, I don't have the problem because, as a developer, I only need leiningen. As a user building from source, I only need leiningen. Both use cases are much simpler.
However, having said that, I was only referring to the developer experience in my comment. I'm not really too sure what you read it as, but like I say above, I don't think it really matters: its a problem either way and both go away with a standard build tool.
Lein evolved to be the winner because afaik it was simply the best at it. If another tool out did it, that would be fine with people I think, but most of what you need (and THEN some) is available as lein plugins, so there's no need to dethrone it.
