What do you mean by the totally outdated approach to concurrency? I'm also a longtime Java dev who's embraced these values for a long time, and I generally thought of using ExecutorServices and Callables as a very functional approach to concurrent programming. If you're referring to manually starting threads and using synchronized monitors to ensure thread-safety, then I agree, but java.util.concurrent really doesn't encourage that approach.
Not the author, but I'd say he's referring to two Clojure features that make programming with concurrency so nice, specifically STM (Software Transactional Memory) and immutability by default. STM is much better (IMO) approach to concurrency than locking, but it's really only viable (as far as I know) in a language like Clojure where values are immutable by default.
The great thing about STM is that it's easily composable, while locking isn't.
It can be done at the page level in an OS if you want. It's not efficient, but then it hasn't been shown to be that efficient in a controlled functional language yet either. Locking still wins on clock cycles, unfortunately.
