"Cookie Clicker Alpha" solution
I have to admit, the actual "solving the problem" component of this is a little over my head. But, I thought I'd try to answer your questions and give you some style/structure feedback, for what it's worth :)

You can simplify your ns declaration like this:

(ns cookie-clicker
  (:require [clojure.string :refer (split)]
            [clojure.java.io :as io]
            [clojure.test :refer :all]))


(:require foo :refer (bar) does the same thing as :use foo :only (bar), and is generally considered preferable, especially as an alternative to having both :use and :require in your ns declaration)

I think Double/parseDouble is a good approach to parsing doubles in string form. Integer/parseInt is usually my go-to for doing the same with integers in string form. This is just a hypothesis, but Double/parseDouble might be faster and/or more accurate than read-string because it's optimized for doubles.

FYI, you can leave out the java.lang. and just call it as Double/parseDouble in your code. In light of that, you might consider getting rid of your parse-double function altogether and just using Double/parseDouble whenever you need it. The only thing is that Java methods aren't first-class in Clojure, so you would need to do things like this if you go that route:

(defn parse-row [line]
  (map #(Double/parseDouble %) (split line #"\s+")))


(Personally, I still like that better, but you might prefer to keep it wrapped in a function parse-double like you have it. It's up to you!)

I think needing to mess with the locale might be a locale-specific problem... I tried playing around with (format "%.7f" ... without changing my locale and it worked as expected. Granted, I'm in the US :)

I think the legibility issues you're seeing might be related to having too many functions. You might consider condensing and renaming things and see if you like that better. I would re-structure your program so that you parse the data into the data structure at the top, something like this:

(defn parse-test-cases [in-file]
  (with-open [rdr (io/reader in-file)]
    (let [rows (rest (line-seq rdr))]
      (map (fn [row] 
             (map #(Double/parseDouble %) (split row #"\s+")))
           rows))))


(I condensed your functions parse-row, parse-test-cases and half of spit-answers into the function above)

Then define the functions that "do all the work" like min-time, and then, at the end:

(defn spit-answers [answers out-file]
  (with-open [w (io/writer out-file :append false)]
    (.write w (clojure.string/join "\n" answers)))

(def -main []
  (let [in  "resources/cookie_clicker/B-large-practice.in"
        out "resources/cookie_clicker/B-large-practice.out"
        test-cases (parse-test-cases in)
        answers (map-indexed (fn [i [c f x]]
                               (format "Case #%d: %.7f" (inc i) (min-time c f x)))
                             test-cases)]
    (spit-answers answers out)))


I came up with a few ideas above:


In your answers function you use (map ... (rest (range)) (test-cases)) in order to number each case, starting from 1. A simpler way to do this is with map-indexed. I used (inc i) for the case numbers, since the index numbering starts at 0.
I condensed (str "Case #" n ": " (format "%.7f" t))) into a single call to format.
I used destructuring over the arguments to the map-indexed function to represent each case as c f x -- that way it's clearer that each test case consists of those three values, and you can represent the calculation as (min-time c f x) instead of (apply min-time test-case).


As for your min-time function, I don't think loop/recur is necessarily a bad thing, and I often tend to rely on it in complicated situations where you're doing more involved work on each iteration, checking conditions, etc. I think it's OK to use it here. But if you want to go a more functional route, you could consider writing a step function and creating a lazy sequence of game states using iterate, like so:

(note: I'm writing step as a letfn binding so that it can use arbitrary values of c, f and x that you feed into a higher-order function that I'm calling step-seq -- this HOF takes values for c, f and x and generates a lazy sequence of game states or "steps.")

(defn step-seq [c f x]
  (letfn [(step [{:keys [factories time-cost cookie-rate total-time result]}]
            (let [new-time-cost (+ time-cost (/ c cookie-rate))
                  new-cookie-rate (+ cookie-rate f)
                  new-total-time (+ new-time-cost (/ x new-cookie-rate))]
              {:factories (inc factories)
               :time-cost new-time-cost
               :cookie-rate new-cookie-rate
               :total-time new-total-time
               :result (when (&gt; new-total-time total-time) total-time)}))]
    (iterate step {:factories 0, :time-cost 0, :cookie-rate 2.0, 
                   :total-time (/ x 2.0), :result nil})))


Now, finding the solution is as simple as grabbing the :result value from the first step that has one:

(defn min-step [c f x]
  (some :result (step-seq c f x)))