If you read the question macro -> with anonymous functions you’ll see that the -> macro doesn’t play well with anonymous functions. To use the macro correctly you need to understand the implementation. In that sense, the macro is “leaky” – the implementation is not completely hidden by the API.
Is it always that case that a (sufficiently complex) Clojure macro is leaky?
[For comparison: A similar issue occurs with the C pre-processor, where strange side effects can be seen when macro arguments are handled carelessly. In that case, issues can be solved by enclosing the macro arguments in parentheses (inside the macro). That does not solve the issue of using C macros with mutable state (ie where each use of the argument mutates state), but perhaps we can either ignore that issue for functional languages, or use let to avoid multiple evaluations.]
You don’t need to understand the implementation – the docstring is quite clear as to how it works. Reader macros are also well documented – #(…) will expand to (fn [..] …). Given this knowledge and the information provided docstring it’s clear that threading anonymous functions won’t work. No need to understand the implementation at all.