Yes, this code is functional. You aren't needlessly mutating anything by abusing atoms or relying on side-effects. Really, those are the major deciding factors.
Shouldn't be there. That should be tucked inside the :require with everything else. Use of :use is discouraged, as is :refer :all in many cases. Blanket unqualified imports of namespaces aren't ideal. Say you come back to this project a year from now. Are you going to remember what functions come from what modules? Unless the names provide enough context, you may have trouble. Bulk unqualified imports also increase the chance of having a name conflict. Always try to use :as, or :refer [...] when importing. That way you can easily see what code is coming from where, and avoid polluting your namespace.
Now, this is a good way of dealing with possibly-nil values. The placement of the check is weird though. Take a look at filter-items-by-term. Why are term and author possibly nil? Because get-feed-data takes optional parameters, and passes the data, unchecked, to filter-items-by-term. This means that part of the implementation of filter-items-by-term (checking for nil values) is needed due to the implementation of get-feed-data (passing potentially nil values). What if you change how one of the functions work and forget to change the other? It also seems needlessly complicated that many of your functions are trying to cover their asses"protect themselves" by assuming that bad data may be handed in. It would be much cleaner to expect that the caller, when possible, checks the data prior to calling. All your functions should expect valid data. If the caller has bad data, it's up to them to fix it. I'd make the following changes:
