I wonder if they meant to write these "key takeaways" in context of performance, or generally? Taken on their own they don't sound too familiar vs why people usually decide to go with Clojure or not.
* "Clojure frees developers from the perils of writing concurrent programs, but at a price."
* "When concurrency is not a factor, consider using Java."
From the first statement, the "price" refers to performance implications. So the second refers to that too and the article mostly talks about performance.
Pure FP generally scales well with caching/memoization, because functions are pure, and with concurrency, because data is immutable. However the paradigm typically allocates more garbage and often creates more indirection due to its declarative nature (think function composition/pipelines/laziness and so on). So it is not as suitable for fine-grained/low level optimizations as imperative programming.
Like dgb23 said the takeaways were in the context of performance.
It's also important to emphasize the part about only seeing performance degradation when the server was at full capacity.
If your service doesn't take your server to its edge, which is most often the case, then there really isn't any advantage writing parts in Java as far as performance is concerned.
This approach shines in those cases where you deal with very high throughput.
* "Clojure frees developers from the perils of writing concurrent programs, but at a price."
* "When concurrency is not a factor, consider using Java."